Re: Automatic tree conflicts resolution during svn update

On 12.06.2013 15:42, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane_at_wandisco.com]
>> Sent: woensdag 12 juni 2013 15:20
>> To: dev_at_subversion.apache.org
>> Subject: Re: Automatic tree conflicts resolution during svn update
>>
>> On 12.06.2013 08:47, Bert Huijben wrote:
>>>> -----Original Message-----
>>>> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
>>>> Sent: woensdag 12 juni 2013 00:28
>>>> To: Bert Huijben
>>>> Cc: Stefan Sperling; 'Johan Corveleyn'; 'Subversion Development'
>>>> Subject: Re: Automatic tree conflicts resolution during svn update
>>>>
>>>> Bert Huijben wrote:
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
>>>>>> Sent: dinsdag 11 juni 2013 23:37
>>>>>> To: Subversion Development
>>>>>> Subject: Re: Automatic tree conflicts resolution during svn update
>>>>>>
>>>>>> On Tue, Jun 11, 2013 at 4:27 PM, Stefan Sperling <stsp_at_elego.de>
>>>>> wrote:
>>>>>> > On Tue, Jun 11, 2013 at 02:12:14PM +0200, Stefan Sperling wrote:
>>>>>> >> On Mon, Jun 10, 2013 at 07:21:19PM +0400, Danil Shopyrin wrote:
>>>>>> >> > The current draft of the Subversion 1.8 Release Notes
>>>>> announces
>>>>>> >> > automatic tree conflicts resolution for locally moved files
>>>>> and
>>>>>> >> > directories. But it seems that this feature does not actually
>>>>> work in
>>>>>> >> > RC2. The detailed reproduction script is given below. I think
>>>>> that we
>>>>>> >> > should either drop this feature from the release notes or
>>>>> provide a
>>>>>> >> > better documentation on how to make it work.
>>>>>> >>
>>>>>> >> The feature is present and works as advertised. It's just not
>>>>> triggered
>>>>>> >> automatically because there were objections to making decisions
>> on
>>>>>> >> behalf of the user.
>>>>>> >>
>>>>>> >> Note that this is the behaviour of 'svn' -- other clients
>>>>> can implement
>>>>>> >> different behaviour and suggest or even hard-code some default
>>>>> option
>>>>>> >> without asking the user.
>>>>>> >>
>>>>>> >> I think the problem with 'svn' is that the menu options
>>>>> were too hard
>>>>>> >> to figure out. After some discussion with Ivan, I've tweaked
>>>>> the
>>>>> conflict
>>>>>> >> prompt menu for clarity in this commit:
>>>>> http://svn.apache.org/r1491762
>>>>>> >>
>>>>>> >> Does this change settle the issue for you?
>>>>>> >
>>>>>> > FYI, this is what the new output looks like:
>>>>>> >
>>>>>> > $ svn up -r3
>>>>>> > Updating '.':
>>>>>> > C alpha
>>>>>> > At revision 3.
>>>>>> > Summary of conflicts:
>>>>>> > Tree conflicts: 1
>>>>>> > Tree conflict on 'alpha'
>>>>>> > > local file moved away, incoming file edit upon update
>>>>>> > Select: (mc) apply edit (recommended), (r) discard edit (breaks
>>> move),
>>>>>> Why does discarding the incoming edit break the (local) move?
>>>> I was wondering the same thing.
>>>>
>>>>> The copy/add part would be of a different revision than the delete part
>>> of
>>>>> the move if you don't apply the move.
>>>> That doesn't make any sense to me as a user. "Discard edit" sounds like
>>> it
>>>> means "act as if the incoming edit was a no-op"... and I would not expect
>>> a
>>>> no-op to break the local move.
>>> The options the interactive conflict editor displays don't reflect the
>>> actual state if you look at it in this way.
>>>
>>> At the time we are resolving the BASE nodes at the original location have
>>> been updated to the target revision, but the place that the code has been
>>> moved to is still at the old revision.
>> I have to wonder why an "svn rename" would affect the BASE tree in any
>> way? I'd expect /both/ ends of the rename to be recorded in the WORKING
>> tree, so that an update won't simply overwrite important state information.
>>
>> In other words -- I suspect this is a design bug.
> The update affects BASE.
>
> Is that a design bug?
>
> Or is it a design bug that it doesn't update working nodes in a completely different location on your harddisk?
>
>
> Update changes BASE, but there are shadowing nodes describing a move, so you get a tree conflict.
>
> One of the resolve options is applying the change over the move. Applying it directly would be a design bug in my book.

Why? You're simply applying text/prop changes to the equivalent node in
the working copy. How can you reasonably argue that tracking moves in
the working copy is bad design?

> $ svn up A/B
>
> could then just affect something at C/D/E/F/H/c, to which we didn't even obtain a write lock.

That's an implementation detail that has nothing to do with the issue.
I'd even argue that we /should/ have taken a lock on the move target if
the move source is in the tree that we're updating (and vice versa, of
course).

> Instead we create a tree conflict somewhere on or below A/B and provide the option to resolve it.

My point is that breaking the move is not a valid option in this case.
So the only option is to either postpone the resolution, or follow the move.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com