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 <bert_at_qqmail.nl> wrote:
>
>
>> -----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.

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/