On Tue, Nov 29, 2016 at 08:00:31PM +0100, Olaf van der Spek wrote: > On Tue, Nov 29, 2016 at 7:38 PM, Stefan Sperling <s...@apache.org> wrote: > > On Tue, Nov 29, 2016 at 07:23:21PM +0100, Olaf van der Spek wrote: > >> On Wed, Nov 23, 2016 at 12:36 PM, Johan Corveleyn <jcor...@gmail.com> > >> wrote: > >> > Maybe Stefan Sperling (in cc) or others working on the tree conflict > >> > resolver have more insight on this ...? > >> > >> Stefan? > >> > >> For directories it seems like a no-brainer to avoid the conflict. > > > > Indeed, adding a resolver option for this should not be very difficult. > > I'd opt for not having a conflict in the first place.
There is a reason the non-conflict behaviour requires the --force option. It is perfectly fine for Subversion to be conservative if the alternative is to litter all over other people's data. And this conflict is not very difficult to solve: When a directory DIR has an "local dir unversioned, incoming dir add upon update" conflict, and you want to keep DIR as it was and do not want SVN to touch it after all, all you need to do is move DIR out of the working copy (with standard operating system tools) to somewhere else and it will have been preserved as it was before SVN got involved. Then run 'svn revert -R DIR' to put the versioned content in place. Note that this solution is not trivial to achieve after update --force which might modify unversioned files, requiring the user to edit files in DIR back into their original state. This is why --force is not the default. If instead you want to make the versioned content of this directory appear in the working copy, all you need to do is run 'svn revert -R DIR'. This won't remove unversioned files inside DIR, but these can now be removed with 'svn cleanup --remove-unversioned DIR' if desired. Caution: Unlike the update --force option, this overwrites unversioned files with versioned files where they occupy the same path, instead of merging such files. As far as I can see, the only nice way to have versioned files merged with unversioned files is to use checkout/update with the --force option which avoids the tree conflict in the first place. (Running 'svn add DIR' after 'svn revert -R DIR' will also merge the files, but schedules an undesirable replacement as well.) So this is something the conflict resolver could handle in a better way than existing svn commands can. However, I'm not very sure how well merging of arbitrary versioned and unversioned content generally works out in practice. Is this really more useful than one of the other two solutions? In summary, these are the options the conflict resolver could offer: 1) move DIR to another place and restore its versioned content 2) discard all unversioned content and put versioned content in place 3) merge versioned and unversioned content where paths overlap (like --force) Nothing new here, expect the ability to get the same behaviour as with update --force after the conflict has been flagged because the user really wants to merge the files (why?) and forgot to use --force. The biggest advantage of offering such options is that users would not have to figure out the resolution steps by themselves. > > Would you like to try writing a patch for this? I think this is a nice > > problem for someone who would be interested in contributing to the new > > conflict resolver code. > > I'd love to but I'm chronically out of time.. Me too!
