On 12.06.2013 15:42, Bert Huijben wrote: > >> -----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.
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. br...@wandisco.com
