Derek Robert Price <[EMAIL PROTECTED]> 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs