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


For the most general case, yes.  A record of all diffs that have been
merged to a location, and multi-step merges would be necessary.  What
would you like a "smart" CVS to do in this case:

~             /-----t1----t2------A
~    ----------------------
~             \-----------------B

~    cvs co -r B project
~    cvs up -jt1 -jt2
~    cvs ci
~    cvs up -jA

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


I see it now, and I thought that the conflicts you now say don't occur
were the ones you objected to in the first place.

Regardless, some of what you said in that email was correct and some
wasn't, but I don't think you can solve the general case without saving
a merge history for each revision of each file.

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


It isn't.  The existing GCA algorithm is merely a convenience to avoid
typing a start-revision in the most common case (merging from a branch
to its parent) and I think it actually confuses more people than it
helps since it always does _something_, even in the not so common cases,
or at least it certainly would confuse more people than it helped if
some sort of autotagging of the base occurred when a branch was created
(Steve Cameron's .base, .parent, .trunk patch would be a nice
alternative to autotagging if someone could fix it and we could commit
it).  As things stand, GCA as a start point is the occassionally the
best you can do if you aren't meticulous about tagging your branch base.

Regardless, its use in the most common case doesn't make it a smart
system.  It is still very dumb, and in fact, if you pass CVS a single
static tag rather than a branch, it will still happily compute the GCA
with the destination of the merge.  This can occassionallly be useful if
you know what you are doing, but it isn't very smart, on CVS's part, and
if you don't know what you are doing it can cause confusion.

Derek

- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
I will not fake my way through life.
I will not fake my way through life.
I will not fake my way through life...

~          - Bart Simpson on chalkboard, _The Simpsons_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/qr7+LD1OTBfyMaQRAgr1AKCh3mVAn3mEFY9+87cvMyAAmG1aKwCgvhJu
pXkEav4/qeHTZT70grI7j4c=
=bisw
-----END PGP SIGNATURE-----