> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: vrijdag 15 februari 2013 15:23
> To: Philip Martin; dev_at_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 <markphip_at_gmail.com>
> wrote:
> > On Fri, Feb 15, 2013 at 9:07 AM, Stefan Sperling <stsp_at_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.
But I think we should keep the current behavior if you update only a
subdirectory, which happens to have some subtree that is moved to another
part of the working copy.
Users will get very frustrated if they update one specific thing and in
another place their source breaks down. I'd rather have an easy to apply (or
hard to apply) tree conflict then unexpected behavior.
I don't see a problem if the only change outside a tree is a revision bump,
but applying actual working copy changes should be limited to what you are
updating.
+1 on making the resolve-bump only fully automatic after obtaining the
proper working copy lock.
** The same user might just have another update or commit running on that
part of the working copy!! **
Bert
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Received on 2013-02-15 16:58:03 CET