Re: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <address@hidden> wrote on 11/06/2003 08:57:22 AM:

> The way to avoid only processing this for whole branch merges is to
> track individual commits as change sets.  For example, store that the
> sum of changesets for file1 1.2 -> 1.2.4.7 have been merged into the
> trunk.  Then later, if a merge is attempted from 1.1 through
> 1.2.4.103.2.17, CVS could notice that the changesets above lay in the
> path and merge 1.1 -> 1.2 & 1.2.4.7 -> 1.2.4.103.2.17 as two separate
> merges.
> 
> If 1.2.4.103.2.1 -> 1.2.4.103.2.10 has already been merged as well, then
> that could be subtracted as well, leaving CVS with three merges:
> 
> ~    1.1 ->1.2
> ~    1.2.4.7 -> 1.2.4.103
> ~    1.2.4.103.2.10 -> 1.2.4.103.2.17
> 
> and so on.

I'm curious, do you think that multi-step merges will be required for the 
general case?

Did you see my response to your original email? You had thought that 
multiple merges were necessary for that example, but when I studied it it 
didn't look that way.

http://mail.gnu.org/archive/html/info-cvs/2003-11/msg00053.html

Isn't it possible that, if I do whole branch merges, I can handle 
everything with single merge operations... subject to caveats:

> No, I don't think there is a general way to handle this.  Or, at least
> the general way is to allow the user to pass a switch or somesuch to
> override the "smart" behavior so the merge can be reapplied.  Note that
> this requires that CVS report when it skips portions of a requested
> merge so that the user will know this is necessary.

Certainly that switch is assumed. But say for the sake of argument that it 
is "all or nothing." In other words, if you want to use the smart merges, 
you have to follow the smart merge rules.

That merely means doing some things a bit differently; for instance, if 
you want to use merge as a tool in more unconventional ways (I want to 
re-merge this branch because changes from it were accidentally deleted), 
you have to find other solutions. In the case of this example, I'd 
envision using the conventional merge operations to easily simulate 
undoing the "mistake" without additional complexity.

> |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.
> 
> 
> No, this would not make CVS smarter about GCA.  This would make CVS
> smarter about merging.  Please do not misuse the term "GCA" this way.
> "GCA" has a well-defined meaning and well-established usage in CVS and
> the algorithm we are discussing has little to do with determining the
> ancestor, except possibly for determining an implicit start point for a
> merge request, which is exactly how the GCA is used currently.

I will be careful not to confuse the term "GCA" with any new, more 
automated system for determining merge start points. I meant to draw the 
comparison only because what I envisioned for such a new system seemed 
functionally very similar to the existing CVS GCA algorithm (in function, 
of course, not in implementation). 

Or am I wrong even in this?