info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question regarding merging


From: Mark Hoogenboom
Subject: Re: Question regarding merging
Date: Mon, 05 Dec 2005 15:35:20 +0000
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221

Right - with latest-good-tag-from-the-branch on the branch, things start to make sense. To update a branch with the latest changes in the trunk, I would say:

1. Tag the latest revisions in the trunk:
cvs rtag tag2 mymodule

2. Update the sandbox containing the branch (where tag1 is the tag from the previous loop)
cvs update -j tag1 -j tag2

3. Solve conflicts and commit.


Jim Hyslop wrote:
-----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-----



  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]