Re: Merging Issues

[Pierre Asselin]

Dhruva B. Reddy <address@hidden> wrote:
> We are doing development on a branch which has been around for a while,
> and I was required to merge in changes from the trunk a few times.

> The first time I did this, I did the following (in a sandbox from the
> branch):

>     cvs up -j HEAD

> and then applied a tag as recommended by the documentation.  This merge
> went as expected (changes made on the trunk were now available in the
> branch, along with the changes checked into the branch).

> A few days ago I merged changes from the trunk again.  I could have
> sworn I did it like this (again, in a sandbox from the branch):

>     cvs up -j <tag created after last merge> -j HEAD

> This resulted in the loss of *all* changes made on the branch (i.e.,
> they were overridden by the versions on the trunk).

> Can anyone tell me what could have caused this (what kind of human
> error, etc.) and how to prevent from happening again?

My guess:  when you planted the <tag created after last merge> you
tagged the branch by mistake, instead of tagging the trunk.  That
would explain why the second merge undoes all the branch work.

Workaround:  don't commit this sandbox where you attempted this
second merge, just delete it and start over.  Now go back to the
trunk and create a new branch.  Get on the new branch.  Merge
the changes on the old branch,

    cvs update -r <new-branch>
    cvs update \
        -j <1st-branch-branchpoint> \
        -j <tag created after last merge>

and go fix the conflicts.  You have to expect vacuous conflicts,
because many changes between <1st-branch-branchpoint> and the tip
of the old branch are also present on the trunk.  The conflicting
text will be the same on both sides, so just pick one.  Sometimes
cvs (diff3, really) manages to get it right but as a rule you
have to expect spurious conflicts.  Well, fix them, that's the
price you'll have to pay.

Commit the new branch, and abandon the old branch.

-- 
pa at panix dot com