info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rephrasing: question about merging branches


From: Derek Robert Price
Subject: Re: Rephrasing: question about merging branches
Date: Thu, 06 Nov 2003 08:57:22 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

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

David Wood wrote:

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


Yes.  And if the example was a child merging to the great grandparent,
the GCA would be where the parent begins.  The GCA is the most recent
ancestor the two revisions have in common.

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


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


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.

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

Derek

- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps it
to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it.  Its peculiar character, too, is that no one possesses the less,
because every other possesses the whole of it.  He who receives an idea
from me, receives instruction himself without lessening mine; as he who
lights his taper at mine, receives light without darkening me.  That
ideas should freely spread from one to another over the globe, for the
moral and mutual instruction of man, and improvement of his condition,
seems to have been peculiarly and benevolently designed by nature, when
she made them, like fire, expansible over all space, without lessening
their density at any point, and like the air in which we breathe, move,
and have our physical being, incapable of confinement or exclusive
appropriation. Inventions then cannot, in nature, be a subject of property.

           - Thomas Jefferson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/qlNBLD1OTBfyMaQRAmoCAJ95jYmQo/0wGbRmi6dEQPgnx+TzawCgrf6/
7rDMDmEsPcj+7CRMlNaz0Sk=
=KlK7
-----END PGP SIGNATURE-----






reply via email to

[Prev in Thread] Current Thread [Next in Thread]