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. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
