Re: Rephrasing: question about merging branches

[Mark D. Baushke]

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

David Wood <address@hidden> writes:

> Derek Robert Price <address@hidden> wrote on 11/05/2003 10:38:02 AM:
> > No.  The GCA has not changed and CVS determines it correctly.  You
> > simply no longer wish to merge from the GCA forward because some of
> > those changes were already merged to your destination (from another
> > branch and at your own request - CVS did nothing wrong) and you wish to
> > avoid conflicts.
> 
> I am not saying CVS is doing anything wrong; I think it is following its 
> design precisely. I think my problem may be with terminology. 
> 
> If I merge from a child to the trunk, and then I later merge it again, 
> what is the greatest common ancestor on that second merge? Still the 
> beginning of the child? Or is it now point of the first merge?

If you want to remember the last point at which you did the merge, then
you can create a tag for that point. Take a look at the cvs.cvshome.org
repository and the cvs1-11-x-branch-last-merge label which we move each
time we merge a change from the cvs1-11-x-branch into the trunk.

> It sounds like you are saying the former - following the strict CVS 
> definition for GCA, that is right. But what about an alternate definition 
> of "ancestry" based on both branches _and_ merges?
> 
> Right now to do that second merge I have to tell CVS where to start - it 
> no longer uses its GCA algorithm to figure that out for me. But I am 
> telling it the new common "ancestor" myself - the point of the previous 
> merge (as opposed to the point of the branch). Isn't this an analogous 
> process to CVS' current GCA? 

I believe you are describing something different.

There is nothing preventing you from renaming the old branch to
something else, branching from your current location, and then merging
your old-branch changes forward into your new branch. Then the GCA
remains correct and cvs does the book-keeping for you.


 Time 1:
      cvs tag -b branchA
      cvs tag -b branchB
      ... commits to branchA and branchB
 Time 2:
      cvs checkout
      cvs up -jbranchA
      ... resolve conflicts
 Time 2':
      cvs commit
      cvs tag -b branchAA
      ... commits to branchA no longer allowed,
      ... commits continue to branchAA and branchB
 Time 3:
      cvs checkout -r branchAA
      cvs tag -b branchBB
      cvs checkout -r branchBB
      cvs up -jbranchB
 Time 3':
      cvs commit
      ... commits to branchB no longer allowed,
      ... commits continue to branchAA and branchBB
 Time 4:
      cvs checkout
      cvs up -jbranchBB
 Time 4':
      cvs commit
      ... commits to branchBB no longer allowed

Now, at such time as branchAA needs to be merged into the trunk, you
will have some conflicts to handle, but I believe you can see that
your methodology of wanting to use the GCA can be accomodated using
cvs, just perhaps not in the manner you might like.      

Original picture:

              branchA  2    3
            /---------\-----\-------->
         1 /           \     \           4'
trunk ------------------*---- \ ---------*---->
           \            2'     \        /
            \-------------------*------/-->
              branchB           3'     4

Revised picture:

                                3'             4 
                              /-*--------------*  branchBB
              branchA 2     3/                  \
            /---------\  /--*-------> branchAA   \
         1 /           \/                         \4'
trunk ------------------*--------------------------*---->
           \            2'            
            \-------------------*
              branchB           3'

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/qTUg3x41pRYZE/gRArcRAKDT9tS5FiNec/f+AjjcAayDLUmDJgCfaRvw
WZ/E5Q3T0oxlB2weUIToHwI=
=BB7V
-----END PGP SIGNATURE-----