[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rephrasing: question about merging branches
From: |
David Wood |
Subject: |
Re: Rephrasing: question about merging branches |
Date: |
Fri, 7 Nov 2003 18:31:39 -0500 |
Derek Robert Price <address@hidden> 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?"
- Re: Rephrasing: question about merging branches, (continued)
- Re: Rephrasing: question about merging branches, David Wood, 2003/11/05
- Re: Rephrasing: question about merging branches, Derek Robert Price, 2003/11/05
- Re: Rephrasing: question about merging branches, David Wood, 2003/11/05
- Re: Rephrasing: question about merging branches, Mark D. Baushke, 2003/11/05
- Re: Rephrasing: question about merging branches, Derek Robert Price, 2003/11/05
- Re: Rephrasing: question about merging branches, Derek Robert Price, 2003/11/05
- Re: Rephrasing: question about merging branches, David Wood, 2003/11/05
- Re: Rephrasing: question about merging branches, Derek Robert Price, 2003/11/06
- Re: Rephrasing: question about merging branches, David Wood, 2003/11/06
- Re: Rephrasing: question about merging branches, Derek Robert Price, 2003/11/06
- Re: Rephrasing: question about merging branches,
David Wood <=
- Re: Rephrasing: question about merging branches, Jamie Wellnitz, 2003/11/05