[cvsnt] Re: Possible bug with mergepoints

[Bo Berglund]

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)