On 7/12/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> So i'm not sure your current idea of stopping as soon as a single
> conflict happens during a merge-range application is a good idea:
>
> 1. It's not what we do now in the same situation (effectively all of our
> non-single rev merges are merge-range applications, the range is contiguous)
> 2. Finishing a large merge would take a very large number of calls to
> svn merge if you have a lot of conflicts, because you are stopping the
> merge each time, even if the conflicts are not in the same files.
> 3. You end up with more work, particularly in the case where the same
> lines get changed *again* in a later revision (now you get two conflicts
> instead of 1).
>
>
> I expect merge to do what i tell it to, and to let me deal with the
> problems that happened as a result. I don't know of *any* VCS tool that
> will stop merge application at a conflict because it thinks it is
> "better for me" in some way :).
>
> At a bare minimum, I would think the user experience would be severely
> affected by a change to stop merge application, unless you would only
> stop merge application if we have a conflict on the same lines of the
> same file between multiple merge ranges.
>
> Even then, i'm still not so hot on the idea, but AFAIK we don't have a
> good way to replace merge markers with a newer set of merge markers to
> handle these cases. :)
I certainly agree that merge should "do what you told it" and then let
you clean up the mess, but I'm not clear how that's possible in this
case.
Say I'm merging r10:20 into my working copy, and I've already merged
r15. That means there are two ranges to merge. When the first range
results in a conflict for a given file that is also modified in the
second range, what should it do? You can't very well try and merge
into the conflicted file, can you? I think the only sane thing to do
is to record that we merged r10:14 into the file in question, but not
touch it at all after that, so you at least have a chance to merge the
rest once you've resolved the conflict.
I feel like you think there's some alternative that better fits the
user's expectations, but I have no idea what it could be...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 19:20:29 2006