On Sat, Aug 24, 2013 at 02:57:50PM -0700, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
> >On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> >> That's just overcomplicating the issue. This doesn't even need to
> >> become a tree conflict.
> >
> >In my opinion it does need to be flagged as a conflict. Because we
> >don't know what the contents of the incoming directory will be nor
> >what the user may eventually want to do to resolve the problem.
> >Making the unversioned directory versioned is just one possible
> >options among several.
> >
> >See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml
>
> I read that and I still wrote and posted the patch because the arguments
> there bear no relation to what _this_ patch does. That post does a fine
> job describing a few challenges for what a more complete system would
> do. This patch just makes the ratchet not cut the user's knuckles when
> they reverse direction, it isn't the fully automated manufacturing plant
> most of this thread seem to be talking about.
Looking at just one use case is not going to help us in the long term.
And I don't think we should hard-code conflict resolution behaviour in
the update/switch/merge logic.
During 1.8 development, I did experiment with hard-coded conflict
resolution choices on several occasions (see, for example,
http://svn.apache.org/r1161219). Those changes got shot down during
peer review, because there were cases where the hard-coded behaviour
was problematic. More importantly, intertwining conflict resolution
with the update/merge logic tends to make the code overly complicated
and fragile once we look past trivial conflict cases.
So our current approach is to always flag conflicts during update and
merge, and then let 'svn resolve' deal with these conflicts in a
separate step. I would consider your patch if it made 'svn resolve'
deal with the tree conflict raised on the obstructing directory,
rather than changing how 'svn switch' behaves now.
We've spent a lot of time on detecting tree conflicts, and in 1.8 we've
also started to improve the interactive menu for tree conflicts involving
local moves. I'd like to see further improvements there, even if it's
harder than patching up a few use cases. I think we'll get a more
flexible and reliable system in the long term this way.
Received on 2013-08-25 11:47:27 CEST