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 <stsp_at_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 <jcorvel_at_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!
Received on 2016-11-29 22:19:11 CET