Garrett Rooney wrote:
> 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.
Uh, so, imagine their had been no two merges, but you had merged the
already-merged revision.
The conflicts in this merge may have come from any single revision
change, but the end result will still represent them all.
Why do you think we should do something different just because we've
elided a revision in the middle?
>
> 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?
Why not?
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...
See above.
>
> -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 20:46:44 2006