On Thu, Oct 28, 2021 at 11:19:43AM -0400, Mark Phippard wrote: > On Thu, Oct 28, 2021 at 11:15 AM Stefan Sperling <s...@elego.de> wrote: > > > > On Thu, Oct 28, 2021 at 10:24:55AM -0400, Mark Phippard wrote: > > > SVN's design handles renames well from a version control history point > > > of view, but it does not handle them well when doing things like merge > > > or even update if you have local mods to a file that was renamed. Git > > > actually handles this much better. SVN has tried to solve it with the > > > tree conflict feature and incremental progress has been made to > > > resolve those tree conflicts better but it still leaves a lot to be > > > desired. > > > > What is left to be desired when updating or merging a renamed file > > with local mods? As far as I know, in current versions of SVN, this > > is working quite well. > > That is good to hear. I have tried to follow all of the progress you > have made over the last few releases but I mainly use Git in day to > day work now and have not gone to trouble of setting up examples to > try it all out. > > Does it all happen automatically now? I thought at one point we still > created the tree conflict and then you had to run svn resolve or > something like that to trigger the resolution?
The tree conflict conflict will still be created. The client will invoke the resolver automatically when this happens. If the resolver detects just one possible conflict resolution option then the client uses this option automatically. The client will prompt only when the resolver offers multiple options. In some cases we might prompt anyway even if just one option is found, but non-ambiguous moves should be followed without further interaction required by the user. The logic for presenting and picking resolution options is fully under the client's control. So some clients might show different behaviour if they have not been updated to make use of new APIs. Clients do not need to care in any way which options are available and how their resolution strategies are implemented. That is all handled by the library. Clients only need to take care of presentation, and perhaps make a decision on behalf of the user if there is only one option. > Does any of the resolution just happen automatically in the libraries > or for something like Subclipse would a bunch of new stuff need to be > exposed to JavaHL and then we would have to fill in an implementation? JavaHL might still be missing some bits, yes. I am not quite sure. Your best starting point would be to check which svn_client_conflict APIs the command line client using and see whether any of them still need to be mapped to Java.
