Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Fri, 18 Feb 2005 16:04:33 -0000, "John Hall" <john-news2 at cambridgetechgroup.com> wrote: >Tony, > >I think I've found a slightly obscure bug when merging files that have been >added on a branch. This is with 2.0.58d on both the client and the server. > >I created a file on a branch, "test-branch", then switched back to the >trunk. Then typed: > >> cvs up -j test-branch >> cvs up >> cvs com > >Doing the second 'cvs up' seems to have the effect of clearing the >mergepoint field for that file, and it is not recorded on the server. If the >straight 'cvs up' is not done, then the mergepoint (in this case 1.1.2.1) is >stored against version 1.2 of the file. If you are merging changes to an >existing file, a 'cvs up' like this does not cause any problems - it is only >in the case of a newly created file on the branch. > I have now tested this in the following manner and I also think it looks like a bug: 1- I have a test module in which I created a test branch. 2- Updated to the test branch 3- Added a file A.txt on branch and committed it 4- Also edited an existing file B.txt on branch and committed it 5- Updated to HEAD 6- Ran cvs update -j BranchName (this got the new and edited file) 7- Ran cvs update again before committing the merges, nothing retrieved 8- Committed the sandbox 9- In WinCvs I ran a graph on the files with this result: File A.txt, added on branch, did not have the red arrow and no mergepoint data. FileB.txt, edited on branch, did have the red arrow and the mergepoint data. Next I repeated the above steps 2-3(C.xtx)-4(edited A.txt)-5-6-8-9 Now the following happened: File A.txt shows the mergepoint and red arrow from the *second* revision on the branch, but not from the first revision. File C.txt shows the red arrow and the mergepoint data so one can see where the trunk revision was coming from Next I edited C.txt on HEAD and committed Then I updated to branch and edited C.txt there and committed Back to HEAD and update -j branchtag. A merge happened. Committed the merged changes Now the graphed view shows two arrows and both mergepoint data are there. Finally I repeated the sequence for C.txt: edit on HEAD-commit-update to branch-edit-commit-update to HEAD-update with merge from branch-resolve conflict-update again-commit This sequence preserves the mergepoint data too, the red arrow is present. So it looks indeed that if a file is added on a branch and committed, then the sandbox is updated to HEAD and then a update -j branch is done followed later by a regular update, then the mergepoint data for the file added on branch disappears and is not available when the final commit is done. But if the same sequence of edits updates and merge followed by update is done on a file that was added and then merged and committed directly then the initial mergepoint is preserved. /Bo (Bo Berglund, developer in Sweden)