> -----Original Message-----
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: woensdag 12 juni 2013 15:20
> To: dev@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:julianf...@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:jcor...@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 <s...@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.
$ 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.
Instead we create a tree conflict somewhere on or below A/B and provide the
option to resolve it.
Bert
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. br...@wandisco.com
