On 17 December 2015 at 14:14, Stefan Sperling <stsp_at_elego.de> wrote:
> On Thu, Dec 17, 2015 at 12:34:46PM +0000, Julian Foad wrote:
>> I mean that if the user doesn't explicitly specify any moves, then it
>> will match by path only, which will result in behaviour similar to
>> today. If the user specifies one or more 'moves', those will override
>> the path matching for the specified element(s). e.g. the user might
>> specify
>>
>> svn merge ... \
>> --match:(src_left="foo", src_right="x/bar", target="foo")
>>
>> to specify that there was a move from 'foo' to 'x/bar' in the source,
>> and this node corresponds to 'foo' in the target.
>
> This UI requires knowledge about moves prior to the merge and
> the question becomes: How does a user know which moves occured?
> This is a hard question for users to find answers for today.
> I'm not sure people are going to be happy while manually searching
> 'svn log -v' output for this information.
>
> So I think we'll need some automated support for finding moves.
> It doesn't need to be perfect, though.
Yes, that's all correct: this is only a first step, and one of the
next steps is to provide mapping input semi-automatically, for example
in the ways you mention.
> Would it be possible to make your new logic accessible from the conflict
> resolver somehow? If a tree conflict is found in the working copy after
> a merge by 'svn resolve', could we ask the user to specify moves, or try
> to auto-detect them (e.g. via move-scan-log heuristics) and offer an
> option to re-run the tree-conflicted merge with your move logic?
> We'd need to be careful however not to destroy local modifiations in
> this process since parts of the working copy may need to be reverted
> to run the merge again.
Yes, that is possible in principle.
> Or perhaps we could have an option which tells svn to try to find moves
> based on move-scan-log (or better server-side information once available)
> before even the first merge operation is attempted. Any moves found would
> be fed into 'svn merge' as you suggest.
>
> svn merge --find-moves ^/trunk
Yes, that's definitely one way we could extend it.
> We could also default to your logic and provide a way to disable it so
> large merges where no conflicts are to be expected can be run without
> move detection overhead, but we provide move-detection by default:
>
> svn merge --ignore-moves ^/trunk
>
> I don't think it's bad if a move-scan-log heuristic misdetects some moves
> or doesn't find all of them. It's going to be a vast improvement over the
> current situation in any case. We can fine-tune the heuristic over time,
> or try to make the server provide better information to the client once
> the client can handle moves this way. Users who want to be in full control
> can choose not to use the heuristics, much like they can still force a
> reintegrate merge today by passing --reintegrate.
Yup.
> Does your solution apply to update operations as well?
Yes, it certainly can and should. In this case, one half of the
mapping (BASE : WORKING) is already known because the WC tracks moves,
which means the user would only have to specify the (OLD_BASE :
NEW_BASE) mapping.
- Julian
Received on 2015-12-17 15:29:12 CET