Derek Robert Price <[EMAIL PROTECTED]> wrote on 11/06/2003 04:37:03 PM: > 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.
Not at all. The conflicts that troubled me were happening because I was double-merging (when bringing B back to the trunk, merging from 1-4 instead of 2-4), _until_ I used the technique laid out in that email. The conflicts in question are what you describe, here: "If A branched first, then 2->4 will attempt to remerge changes made to the trunk between the base of A and the base of B, causing the same sort of spurious conflicts you were attempting to avoid." And that did not seem to be true. It seemed to me that those changes are not merged twice - as I said, "The changes between the start of A and the start of B are not in A, and they are inherent in B." So I am wondering if I tested it wrong and am thinking about it wrong? > 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. If individual files can't merge, and only whole branches can, I confess I don't understand why that is true, unless by saying the "general case" we are actually discussing something different than I imagine. One other thing I was wondering about was what I found when experimenting with the approach you suggest (using multiple merges): that conflicts arise during the interim steps, making the process unworkable. I am interested in single-step merges both because it _seems_ possible generally to construct one appropriate to a given case, and because they appear to me to avoid the issues of conflicts during interim merge steps. > 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 Let me clarify what I mean a bit more. I want to generalize the process of finding a merge start point based on merge and branch information. I think the CVS "GCA" system is an interesting approach when working with branch information alone. If I understand it correctly, it is analogous to walking backwards up the ancestry of the source branch, searching for the most recent branch point on any common parent, of the souce or the destination branch (whichever is older). What I am experimenting with is the notion that if you add merge information to the mix, this approach still works. I am gathering that you don't think it will; but I guess what I am wondering, in that case, is, "how will it fail?" _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
