On 17 December 2015 at 14:14, Stefan Sperling <s...@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
