On Mon, 12 Mar 2007, Peter Lundblad wrote:
> Mark Phippard writes:
> > Anyway, I think Peter has been pointing out that with the current merge
> > algorithm you can easily have that problem anyway and his alternative
> > approach potentially makes it better. So he is not saying the working copy
> > is inconsistent in terms of corruption, just that the working copy could be
> > logically inconsistent making it difficult to resolve conflicts.
>
> Exactly, and whether to stop merging after a step with conflicts or not in
> my proposed algorithm is a UI question. Do you prefer (revisions-wise)
> consistency or do you want the merge to preceed as long as it can. As I
> pointed out earlier, if you stop at conflicts, you could try to bring the
> rest of the tree into a consistent state by cutting ranges at the end revision
> of the current step. It is not clear to me whether this makes the
> situation better or wose, though.
I'm very much in favor of Peter's proposed change -- strong +1!
I personally prefer that a consistent set of revision ranges be
applied to my WC when doing a 'merge', as it makes resolution of merge
conflicts much easier because the content of my WC is left in a
(logically) consistent state. As I'm typically not merging anything
which will conflict during application of an initial set of revision
ranges and then be removed by a subsequent set of revision ranges, the
behavior described by Peter is my ideal.
That said, I have heard from various folks that they do want 'merge'
to be able to apply as much of the requested change as possible, then
allow them to resolve conflicts after the fact. I've heard this use
case come up in terms of 'merge' scalability, when merging extermely
large data sets with significant drift between branches. Personally,
I wouldn't want to be the one to have to clean up the mess left by
this style of merge, and prefer to use some type of merge summary
(e.g. 'diff --summarize') in conjunction with more careful use of a
'merge' which applies revision ranges in a consistent fashion (as
described above).
- application/pgp-signature attachment: stored
Received on Tue Mar 13 22:42:35 2007