Re: trunk to branch and branch to trunk merge problem

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

das deniz wrote:

|Derek, group, here's a more step-by-step description of how to create
|this problem - provided with the hope that some actual cvs coder will
|attempt a fix and can use this to see if the fix works.
|
|I also have other comments to previous responses inline below.
|
|single merge out to a branch and single merge back into trunk can
|revert changes to all files that were created in the trunk after the
|branch was created.
|
|this is reproducible in all cvs versions tested 1.10, 1.11.2, 1.11.6
|
|here are commands that can be used to reproduce this problem.
|   
|1) (start in up to date working area based on trunk)
|   cvs tag -b branch_name
|   (branch_name versions created, working area is still trunk)
|
|2) cvs add new_file.c
|   cvs ci -m "creation of file after branch created" new_file.c
|
|3) cvs tag first_tag
|   (mods to new_file)
|
|4) cvs ci -m "mods to file after first_tag of trunk" new_file.c
|
|5) cvs up -r branch_name
|   (now in up to date working area based on branch: branch_name)
|   cvs up -kk -j first_tag
|   cvs ci -m "merge of first_tag out to branch_name"
|   (creates branch rev of new_file.c based on HEAD version)


Sounds like the code that determines the GCA is screwing up when there
is no GCA (the file doesn't exist on one branch or the other).  The fix
is probably to make sure that CVS uses empty file contents for the
branch with the missing file in this case.

|   (better would be to base version of file rev used for merge)
|
|6) cvs up -d -P -A
|   (now in up to date working area based on trunk)
|   cvs up -kk -j branch_name
|
|7) cvs ci -m "merge of branch_name into trunk complete"

|on completion of (7) the file contents of new_file.c are reverted to
|first_tag version in trunk (loosing changed commited in (4)). i 'feel'
|this is a problem though it seems currently to be 'correct' cvs
|behavior.
|
|this is likely because there is no branch version created for files
|which are created in the trunk after a branch was created. this does
|not occur when creating new files in the branch because the trunk gets
|a default version in the attic when files that are not in the trunk
|are created in branches.


Yeah, CVS couldn't find a GCA and screwed up.  This case should have
raised the "file exists but has been added" error, as per Issue #141:
<http://ccvs.cvshome.org/issues/show_bug.cgi?id=141>.  The soultion is
probably the same one I mentioned above.

|i only have a guess at the command options needed to avoid this
|problem and, again i 'feel', the solution is not only 'non-intuitive'
|but also 'non-cvs intuitive'.
|
|6) cvs -kk -j first_tag -j branch_name  
|   (diff trunk vs branch to get branch change-set
|   for merging into trunk? ok. but this is not what
|   all the cvs primers use for branch examples....)


This almost certainly wouldn't have done what you wanted since the
first_tag tag does not exist on the branch listed in the second -j
argument.  You would have needed to tag the base of branch_name before
creating the branch.

|would it be possible to make mods to CVS itself to use the revision of
|the file used at the time of the merge out to the branch as the base
|for the later creation of the new-born branch version?
|
|more comments to previous responses inline below. thanks very much.
|
|das
|
|Derek Robert Price <derek@ximbiot.com> wrote in message
news:<mailman.1266.1062179638.29551.bug-cvs@gnu.org>...
|
|>|cvs ci -m "committing merge of first_tag into branch results"
|>|
|>|(creates rev 1.2.2.1 of new_file.c  !!!????)
|>|
|>|WHY ISN'T THIS REV 1.1.2.1 or something based of the rev related to
|>first_tag?
|>
|>
|>Because the branch tag didn't actually exist in this file and CVS
|>defaults to grabbing the latest version.  By the time you commit this
|>file CVS no longer remembers the details of the merge and, lacking a
|>branch tag, creates the new version of the file on the branch based on
|>the most recent trunk version.
|>
|>This would not be easy to change.
|
|
|But this seems a brilliant oversight that does need fixing, no?!
|
|Perhaps cvs could use the version being merged out as a base to create
|an attic branch version that's dead (created at the time of the merge)
|until the file is checked in no (and then it wouldn't need to be in
|the Attic anymore)? i have almost no idea what i'm talking about (cvs
|source code wise) but does this sounds reasonable?


Why worry about CVS's internal revision number when it doesn't change
the operation?

|>|5) MERGE THE BRANCH BACK INTO THE TRUNK
|>|
|>|cvs up -A
|>|cvs up -j my_module_branch
|>|cvs ci -m "merge of my_module_branch into trunk"
|>|
|>|(creates rev 1.3 of new_file.c with contents of rev 1.1)
|>
|>
|>This though, is suprising and almost certainly not what the merger
|>desired.  I'm not quite certain how to go about fixing it.  Is this
|>another argument for always creating dead revisions as branch bases for
|>added files?  Perhaps for all files always having a dead 1.1?
|
|
|maybe... i think my previous inline blurb is something along this
|line.


The GCA fix I mentioned above should be easier and work just as well.

|>The workaround is to tag the base of your branch, e.g.
|>`my_module_branch_base' in this example, then do your merge like:
|>
|>
|>~    cvs up -j my_module_branch_base -j my_module_branch
|
|
|how do these particular merge tags help? isn't this the same as
|
|    cvs up -j my_module_branch
|
|if no previous merge was done from the branch to the trunk?


No, because this works around the GCA bug thus:

Normally, when you specify a single argument to -j, CVS uses it as the
_second_ argument and works out an implicit first argument based on the
Greatest Common Ancester (GCA) of the "second" -j revision and the
destination revision.  The CVS developers usually recommend using two -j
arguments regardless since things can get nasty (though working as
specified, this is an RTFM case often missed by new users) when using
branches of branches, for example.

In this case, you have discovered a bug in the GCA routine, I think, and
it should be fixed as I mentioned above, but it should be a viable
workaround to specify both arguments to -j since CVS will then not
attempt to compute a GCA but will properly use an empty revision when
either tag does not exist in a file.

Patches gleefully accepted!

Derek

- --
~                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
- --
I used to think people were crazy to get tatoos.  Nowadays, I envy
them that clarity of thought.  There was at least one point in their
lives when they thought they knew what they were doing.  They could walk
into a tatoo parlor and say, "I want a big old pig, in red and black,
with flames shooting out of its nose!  And I want it right there!
That's who I am!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/ZzOYLD1OTBfyMaQRAuQ0AJ0d2r6nDGMyANseAJoKVTohlWnp1ACg7BcM
4KJknBmgntpeXSOEXe36ydQ=
=Nl/9
-----END PGP SIGNATURE-----