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.

-- Brane

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