Re: trunk to branch and branch to trunk merge problem

[das deniz]

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)
   (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.

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....)

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?

> |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 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?