Re: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <address@hidden> wrote on 11/05/2003 12:43:14 PM:
> "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.

So in other words, you are saying: in the case where the branch (child) of 
a branch (parent) merges back to the trunk (grandparent), the GCA is on 
the grandparent, at the point where the parent begins. Right?

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

I am hopeful that someone will be me.

My initial approach has been to use a "wrapper" which executes branches 
and merges, generating and applying tags in addition to branching and 
merging, and maintaining extra state data in a database. I believe that 
the tool has all of the necessary information available; the question now 
is using it to determine the correct "merge start point" in a general way.

I only intend to support whole branch merges, and I have been under the 
impression that I can focus solely on eliminating over- and under-merging. 
I believe cases such as your examples, where it is desirable to double 
merge, or to deliberately eliminate part of the merge, cannot be handled 
in a general way - although perhaps you will disagree?

My cursory examination of CVS's GCA algorithm leaves me with the 
impression that it relies on properties of the revision numbering system, 
which if true makes it abundantly clear why there is no simple path to 
making CVS smarter about GCA, even if it did have the information about 
merge activity that it needed.