> -----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.
Doing nothing keeps you in a state where the move is broken... And choosing
mark as resolved will remove the move information that makes a move a proper
copy (of the old version)+delete
The other option is updating the move target, to make it match the new
moved-from revision.
Bert
>
> - Julian
Received on 2013-06-12 08:48:43 CEST