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.
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.
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
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.
Does your solution apply to update operations as well?
Received on 2015-12-17 15:15:02 CET