JakubH Posted October 22, 2012 Report Share Posted October 22, 2012 I've found a bug in a new tree view of branches: There are not all my branches visible in a tree view of branches: Here is the correct list in a list view: It might be connected with visibility in a Branch Explorer somehow. The rel_4_0 branch was hidden there, but it is displayed now. Link to comment Share on other sites More sharing options...
manu Posted October 22, 2012 Report Share Posted October 22, 2012 Wow! Thanks for reporting. I'll test it right now! Link to comment Share on other sites More sharing options...
manu Posted October 24, 2012 Report Share Posted October 24, 2012 Unfortunately I'm not able to reproduce this issue. Can you please give me more details? Is the issue reproducible in your environment? Link to comment Share on other sites More sharing options...
JakubH Posted October 25, 2012 Author Report Share Posted October 25, 2012 It is still there for those two branches, but I cannot reproduce it for another branch. Changing visibility in a Branch Explorer does not affect the Branches view at all. When I open the Branches view, all branches are visible correctly, but when I hit reload button in the tree view, two branches disappear. Strange. Link to comment Share on other sites More sharing options...
manu Posted October 25, 2012 Report Share Posted October 25, 2012 Hi Jakub, Your branch names make me think that's a test repository, isn't it? Would it be possible to share the databases in order to see if I can reproduce the issue? Can you please also confirm the Plastic SCM version you are using? Link to comment Share on other sites More sharing options...
JakubH Posted October 25, 2012 Author Report Share Posted October 25, 2012 It is a test repository, but with real data of our company. Therefore I cannot send it to you. Sorry. (The databases have about 600 MB, so it wouldn't be easy anyway.) My client's version is: 4.1.10.361 - Zurich (from you through this forum) Server was 4.1.10.345 - LosAngeles, but I've updated now to the 4.1.10.361 - Zurich Link to comment Share on other sites More sharing options...
manu Posted October 25, 2012 Report Share Posted October 25, 2012 Ok! Thanks for the info. Is it possible an online meeting? Just to see if we can grab some tips.... Link to comment Share on other sites More sharing options...
JakubH Posted October 25, 2012 Author Report Share Posted October 25, 2012 I probably wouldn't have time today, but I may have time tomorrow morning. Link to comment Share on other sites More sharing options...
manu Posted October 25, 2012 Report Share Posted October 25, 2012 Ok! Keep me in the loop. I'll continue testing. Link to comment Share on other sites More sharing options...
JakubH Posted November 15, 2012 Author Report Share Posted November 15, 2012 I almost forgot this bug, I reinstalled server and reimported data, but it appears again. Now I'm pretty sure, that it has nothing to do with visibility settings in a branch explorer, cause I've not change it so far. I was thinking if it could be somehow connected with a fact, that those branches was created during a fast-import. I have three repositories now. All of these have a branch main and a branch rel_4_0. All used to be one CVS repository in the past. Two of these repositories are affected by this bug, but one of them works correctly. Link to comment Share on other sites More sharing options...
manu Posted November 15, 2012 Report Share Posted November 15, 2012 How are you importing the data? Git? Would it be possible to create a nodata package and send it to us to reproduce the issue? Link to comment Share on other sites More sharing options...
JakubH Posted November 15, 2012 Author Report Share Posted November 15, 2012 The import procedure was quite complex. I might post about it someday, because it was really challenging. But for short, I did these steps: - do some handwork in CVS repository - produce fast-export file using cvs2git with fine tuned configuration - import to GIT using fast-import - do some cleaning in GIT repository - export from GIT using fast-export - do some adjustments on the fast-export file using my own utility (among other things it converted lightweighted tags to annotated ones and remove some changesets, incorrectly generated by cvs2git) - import to Plastic using fast-import I am not sure if I can do the nodata export, because of the utility which alters the fast-export file. But among other things, my utility change names of the master branch to main and name of a rel_4_0 branch to main/rel_4_0. So it looks like this for instance: commit refs/heads/main/rel_4_0 mark :148994 author autotools <> 1352421204 +0000 committer autotools <> 1352421204 +0000 data 19 autobuild commited from :148991 M 100644 :148992 Clarity.xml M 100644 :148993 CswExt/include/version_common.h Do you think that the import could affect the behavior of the branches view? Link to comment Share on other sites More sharing options...
manu Posted November 15, 2012 Report Share Posted November 15, 2012 I'm not sure, maybe we can test it directly from Plastic, just to test if it fails. cm fe XXX --nodata You can fast-import it into a new Plastic SCM repository and see if the branches are not displayed, if they're not displayed please email me the package and we'll debug the issue. Link to comment Share on other sites More sharing options...
JakubH Posted November 15, 2012 Author Report Share Posted November 15, 2012 Wow. It helped. I notice that there are commit refs/heads/main-rel_4_0 instead of commit refs/heads/main/rel_4_0 in Plastic fast-export file. The reimport converts it to /main/rel_4_0 again. So I'll change my utility to generate fast export with dashes instead of slashes and I maybe add one step into my import procedure: fast-export from Plastic and reimport it again. :-) Link to comment Share on other sites More sharing options...
manu Posted November 15, 2012 Report Share Posted November 15, 2012 Cool! Keep us updated! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.