> -----Original Message-----
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: vrijdag 15 februari 2013 16:07
> To: Bert Huijben
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: move conflict resolution UI (was: Re: branch 1.8 or at least
start
> making alpha releases?)
>
> On Fri, Feb 15, 2013 at 9:57 AM, Bert Huijben <b...@qqmail.nl> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Mark Phippard [mailto:markp...@gmail.com]
> >> Sent: vrijdag 15 februari 2013 15:23
> >> To: Philip Martin; dev@subversion.apache.org
> >> Subject: Re: move conflict resolution UI (was: Re: branch 1.8 or at
least
> > start
> >> making alpha releases?)
> >>
> >> On Fri, Feb 15, 2013 at 9:20 AM, Mark Phippard <markp...@gmail.com>
> >> wrote:
> >> > On Fri, Feb 15, 2013 at 9:07 AM, Stefan Sperling <s...@elego.de>
wrote:
> >> >
> >> >> Note that I am referring to options offered by the CLI user
interface,
> >> >> not the API. The API might expose more low-level operations as has
> been
> >> >> requested by GUI client developers in the past. But since we haven't
> >> >> really advanced the conflict resolution API yet, I suppose we should
> >> >> try to do the best we can do for 1.8 using the existing API.
> >> >
> >> > I would be fine if the API provides more options, as long as it also
> >> > provides the same options as the CLI. IOW, if the CLI has an option
> >> > to resolve conflicts and under the covers it resolves different
> >> > conflicts in different ways, I would want a simple option like that
in
> >> > the API too. I would not want to have to reimplement the same
> >> > decision logic as the CLI and then call a lower level API.
> >>
> >> Since I have seen this mentioned on IRC, let me also just add that I
> >> think ideally update should just resolve these conflicts automatically
> >> and never even raise them to the user. IOW, if I have moved a file
> >> locally and I do an update I would want update to just apply those
> >> changes to the moved file automatically. This would show up as a 'G'
> >> in the update notification, and I think that is good enough in terms
> >> of letting me know. If I did not want the updates applied to my file,
> >> then I would have copied it, not moved.
> >
> > I think the default of applying moves is great when the user updates the
> > entire working copy.
>
> Yes, I would be in agreement with that. Although I would probably say
> rather than "entire" working copy, "entire relevant" working copy?
> For example, C-Mike and others maintain a sparse working copy of the
> entire /subversion repository. If he is updating his
> /subversion/trunk folder it should still apply this behavior if all of
> the incoming updates only touch paths within that tree. If some path
> that is outside the scope of the update would be touched, then yes a
> tree conflict ought to be raised. It might be nice if a subsequent
> update that encompasses more of the tree could auto-resolve the tree
> conflicts created from that earlier update. IOW, if update suddenly
> has everything it would need to resolve that conflict, it would be
> nice if it could do that.
I didn't write it down, but my intention would be to auto resolve everything
within reach of the update.
(root = root of wc)
root/trunk
root/branches
root/branches/1.6.x
root/branches/1.7.x
svn up root/trunk
So in this case if you update just 'trunk', any conflicts on moves within
the tree starting with trunk would be applied automatically, but a
functional update via a move from trunk to somewhere in branches/1.7.x would
cause a tree conflict.
It is a bad example to move files between branches, but in this case it
explains the scope of the operation :)
Bert
