> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: woensdag 12 juni 2013 16:13
> To: dev_at_subversion.apache.org
> Subject: Re: Automatic tree conflicts resolution during svn update
>
> On 12.06.2013 15:42, Bert Huijben wrote:
> >
> >> -----Original Message-----
> >> From: Branko Čibej [mailto:brane_at_wandisco.com]
> >> Sent: woensdag 12 juni 2013 15:20
> >> To: dev_at_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: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.
> > 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).
But one that breaks an important use case of using changing different parts of the same working copy at the same time. Implementing this requirement would require breaking backwards compatibility in ways that the Subversion 1.0-1.6 client libraries would never be able to use the new working copy.
I think that would require going to 2.0.
(This was discussed during 1.7 development and last years (and the year before's) hackathon
>
> > 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.
If the incoming change is a move to a different location and changes, users might really want two continue with one copy and one move of the original node. We should not just deny it because it doesn't fit the one use case we are looking at right now.
Your working copy could be years old and you might just want to store your changes... It is insane to require the users to always resolve a move as a move, whatever change comes in. The common/recommended case/choice should be to keep the changes, but it should not be the only option.
There are many cases where an 'svn mv' is part of a larger restructuring operation, and in some of these cases these will conflict with other restructuring operations. We should provide options to resolve these cases, instead of forcing users to revert to get back to a working situation.
Especially since we only enforce move semantics in the client and not at the server. So a move committed by somebody else will just create a different kind of tree conflict and you lose the move tracking anyway.
If the merge tracking is 100% implemented on the repository and during merges we can improve the behavior, but we shouldn't just block the way moves (aka 'svn mv') worked since pre Subversion 1.0 as there are many cases where this just worked right.
And just as there are cases where you don't want these move semantics for a move, there are cases where you *do* want to apply this behavior to copies... (But not in all cases of course)
Bert
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane_at_wandisco.com
Received on 2013-06-12 16:30:55 CEST