Re: Question regarding merging

[Jim Hyslop]

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

Mark Hoogenboom wrote:
>> From: Jim Hyslop <address@hidden>
> Norman Crisp wrote:
>  
> 
>>>> Could someone please confirm that my steps to performing a merge from a
>>>> branch to trunk is correct.
>>>>
>>>> 1- fresh checkout of the trunk into an empty sandbox
>>>>     - cvs checkout -P -kk module-name
>>>> 2- update from the branch into the checked out trunk sandbox
>>>>     - cvs update -kk -P -jlatest-good-tag-from-the-branch
>>>> 3- resolve and conflicts that may have occurred
>>>> 4- commit all changed files back into the truck
>>>>
>>>> Historically I have found conflicts that are not really conflicts due
>>>> to the
>>>> Revision keyword.  This is why I specify -kk on both the initial
>>>> checkout
>>>> from the trunk and also on the update from the branch.  Although the
>>>> results
>>>> look correct, I am not %100 certain that this is the correct method.
>>>>   
> 
> 
> That is one correct way to do it. To expedite future merges, you need to
> apply a second tag:
> 
> cvs rtag -rlatest-good-tag-from-the-branch last-merge-point
> 
> (I am assuming latest-good-tag[etc.] is a non-branch tag, if not, then
> you need to apply a non-branch tag and re-do the merge specifying that
> new tag).
> 
> In subsequent merges, you then specify two -j options:
> cvs update -kk -jlast-merge-point -jeven-later-good-tag-from-the-branch
> 
> then, when the merge is committed, move 'last-merge-point':
> 
> cvs rtag -F -reven-later-good-tag-from-the-branch last-merge-point

>>
> I guess this is all quite elementary, but could you repeat your answer
> in slow-motion? I assume that after step 1 the sandbox contains the
> latest revisions from the trunk. But then if
> latest-good-tag-from-the-branch is a tag on the trunk, what does step 2
> do? How do we end up with revisions from the branch in the sandbox to
> commit?

SSSStttteeeeepppp ooonnneee:
(OK, sorry, I couldn't resist ;=)

No, latest-good-tag(etc) is on the branch, indicating the tip of the
branch (or a known good snapshot on the branch) at a particular moment
in time. The command could just as easily have specified the branch tag,
but as I mentioned earlier, using a non-branch tag expedites any future
merges from the branch to the trunk.

Then, step 2:

>>>> 2- update from the branch into the checked out trunk sandbox
>>>>     - cvs update -kk -P -jlatest-good-tag-from-the-branch

First, a brief explanation on what the CVS merge command does. The CVS
merge command is a two-step process: first, CVS determines the
difference between two source revisions. Second, CVS then applies that
difference to the target revision, which is determined by the revision
that is currently checked out.

The two revisions are specified by the -j options: 'cvs update
- -jFrom-revision -jTo-revision'. If only one -j option is specified, then
it is the 'To-revision', and the 'From-revision' is the common ancestor
of the 'To-revision' and the revision currently checked out.

In this case, the common ancestor is the branch point, so 'cvs update
- -jlatest-goodyadayada' will determine what changed on the branch, and
apply that to the current directory. Since the current directory is the
head of the trunk, we have just merged the changes from the branch into
the trunk.

> Another (related) question: is it possible to merge the trunk with a
> branch instead of the other way around? That is, the branch will contain
> changes in the trunk since the branch was created, but the trunk won't
> contain the changes on the branch.

Yes, exactly the same sequence applies. Rather than tell you the answer,
though, I'm going to tell you that everything you need to know is
contained in this message, and ask you to post what you think the
command sequence will be. Hint: what is the target revision, and what
are the source revisions?

Don't you hate pop quizzes? :=)

- --
Jim Hyslop
Dreampossible: Better software. Simply.     http://www.dreampossible.ca
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDlFkBLdDyDwyJw+MRAo6eAJ47o+Gfd9y/TuwiV8ai+hvPfdoQVwCgpfrC
OsxeQha6dMF0A/VFStbVbu4=
=aa3g
-----END PGP SIGNATURE-----