Re: Rephrasing: question about merging branches

[Derek Robert Price]

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

David Wood wrote:

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


"Greatest Common Ancestor", or GCA, is a term that refers to the RCS
revision structure and always means the more recent revision two
revisions have in common, often a branch point, but in the case of a
branch of a branch and the trunk, note that the GCA is on the trunk, not
the base revision of the branch, but the base revision of its parent.

CVS determines GCA when you only specify one revision in a merge as a
convenience for the common case, merging from a branch into its parent.
This does not mean that the first revision of a merge specification
should always be called a "GCA".

Yes, it would be convenient if CVS were smart enough to track what data
has already been merged to various locations and attempt to
intellegently exclude these data sets in following merges.  This has
been suggested many times in the past.

In practice, CVS does not currently keep track of the necessary data and
even if it did, the problem is a very hard one.  There _are_ reasons a
user could wish to specify a merge twice.  They accidentally copied old
files over the new ones which had contained the merge; another developer
removed the merge changes by hand and committed in conjunction with code
you do not want removed.  etc.    Basically, CVS would have a hard time
tracking what you manually did to its merge result.

If someone were to solve this problem and submit a patch that
implemented the solution including documentation and tests cases which
addressed these sorts of issues and any others that arose, believe me, I
would be one of the first to vote that CVS incorporate the code.

Derek

- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
Rick:  How long was it we had, honey?
Elsa:  I didn't count the days.
Rick:  Well I did, every one of them.  Mostly I remember the last one.
The wow finish.  The guy standing on the station platform in the rain
with a comical look on his face because his insides had been kicked out.

       - Humphrey Bogart & Ingrid Bergman, _Casablanca_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/qTaxLD1OTBfyMaQRAt3BAKDeIjDhRp+rajEaTD30chF3aykn3gCgvYr7
+61vwUYOZrfW7PEdgl9AoQE=
=8AGB
-----END PGP SIGNATURE-----