You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Danil Shopyrin <da...@visualsvn.com> on 2013/06/10 17:21:19 UTC
Automatic tree conflicts resolution during svn update
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 current draft of the Subversion 1.8 Release Notes says the following:
[[
svn update, svn switch, and svn resolve can now automatically resolve
tree conflicts involving locally moved files or directories.
]]
But I'm unable to make it work. Experimenting with SVN 1.8 RC2 I'm
getting the following behavior:
1. Suppose that we have two simple working copies of repository with a
'Program.cs' file.
2. Rename the 'Program.cs' to the 'SuperProgram.cs' file in the first
working copy:
[[
svn move Program.cs SuperProgram.cs
]]
3. Modify and commit the 'Program.cs' file in the second working copy.
4. Update the first working copy using the 'svn update'.
5. Get the following conflict resolution message:
[[
Tree conflict on 'Program.cs'
> local file moved away, incoming file edit upon update
Select: (p) postpone, (mc) my side of conflict, (r) resolved,
(q) quit resolution, (h) help:
]]
I do not consider this behavior as *automatic* because of the following:
* it requires user to make a non-trivial decision;
* there is no option like "resolve automatically";
* it requires user action for all moved files and folders.
So my questions are the following:
1) Is there a simple way to enable automatic conflict resolution
during the update? Am I missing something?
2) Should we drop (or reword) this feature from the Release Notes?
Thanks!
P. S. My own opinion is that automatic conflict resolution for moved
files is "The Number One Required Feature" for Subversion. I prefer to
have this feature released in SVN 1.8 (even only for 'update' and
'switch'). But I'm not sure that this is possible because there is
some push to make SVN 1.8 released quickly.
--
With best regards,
Danil Shopyrin
VisualSVN Team
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 12, 2013 at 02:59:26PM +0400, Danil Shopyrin wrote:
> The new prompt menu makes a great improvement. The most important part
> is that 'apply edit' action is marked as 'recommended'.
I've gone one step further and removed the non-recommended option
from the prompt. It now looks like this:
> local file moved away, incoming file edit upon update
Select: (mc) apply update to move destination, (p) postpone,
(q) quit resolution, (h) help:
> But is it possible to make the solution even better and apply edits
> automatically without prompting users?
Yes, but not in 1.8. We're too late in the release cycle for that.
To do this properly we need to enhance the APIs. See my reply to
Johan about this.
> Also I agree with the idea that this case is not a real "tree
> conflict" (from the user's point of view). The real "tree conflict" is
> when user renames 'Program.cs' to 'SuperProgram.cs' while the file is
> already renamed to 'MegaProgram.cs' in the repository. The discussed
> use case is much simpler and it's not treated as a conflict by most of
> the users.
We could introduce a concept of conflicts which are 'trivial' to
resolve. I think it makes sense to treat these situations as tree
conflicts in the the implementation and also parts of the UI,
because storing and displaying information about them seperately
from other tree conflicts would be awkward.
Re: Automatic tree conflicts resolution during svn update
Posted by Prabhu <pr...@collab.net>.
On 06/12/2013 06:57 PM, Johan Corveleyn wrote:
> On Wed, Jun 12, 2013 at 3:25 PM, Stefan Sperling <st...@elego.de> wrote:
>> On Wed, Jun 12, 2013 at 03:04:56PM +0200, Johan Corveleyn wrote:
>>> Okay, but doesn't "postpone" still needs to have a well defined
>>> behavior (and probably "as good as possible"), even if only for
>>> supporting the --accept=postpone command line option?
>> What is "as good as possible"?
>>
>> The --accept postpone option (or equivalent menu option) simply
>> leaves the conflicted node as-is. I don't think we can make the
>> incoming edit visible without updating the moved file.
> I'd say, just edit the moved file with the incoming content, embedded
> in conflict markers, just like what we do for text conflicts. That, I
> think, would be as good as possible.
>
+1 on the thought
--Prabhu
Re: Automatic tree conflicts resolution during svn update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jun 12, 2013 at 5:46 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jun 12, 2013 at 05:24:39PM +0200, Johan Corveleyn wrote:
>> On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling <st...@elego.de> wrote:
>> > On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
>> >> I'd say, just edit the moved file with the incoming content, embedded
>> >> in conflict markers, just like what we do for text conflicts. That, I
>> >> think, would be as good as possible.
>> >
>> > That's basically what updating the move is doing anyway.
>> > I wouldn't want to apply the incoming changes to the moved file
>> > without also clearing the conflict marker.
>>
>> But that's what we do with text conflicts if you postpone them. We
>> modify the working file (with conflict markers), and leave the
>> conflict in place.
>
> No. The conflict markers are already there when the resolver runs!
> They are the result of a diff3 merge performed during the update.
For reference, Stefan and I continued this discussion on IRC:
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2013-06-12#l183
In the end it dawned on me that the big difference with text
conflicts, is that we don't have / store the complete representations
of both sides of the conflict in the working copy (e.g. tree.mine,
tree.rN, ... like file.txt.mine, file.txt.rN, ...). That makes it near
impossible to implement a general "postpone" that keeps around
everything for you to look at (and still have the ability to rerun the
resolver to choose other options).
Perhaps there could be a special solution for the simple case under
discussion (single file move with an incoming edit on that file), but
certainly not a general solution for tree conflicts.
BTW, Stefan, I really like the 1.8 improvement, it's already a big
step forward (so this is not intended as criticism... just thinking
out loud trying to make sense of it all, and looking further ahead).
--
Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 12, 2013 at 05:24:39PM +0200, Johan Corveleyn wrote:
> On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling <st...@elego.de> wrote:
> > On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
> >> I'd say, just edit the moved file with the incoming content, embedded
> >> in conflict markers, just like what we do for text conflicts. That, I
> >> think, would be as good as possible.
> >
> > That's basically what updating the move is doing anyway.
> > I wouldn't want to apply the incoming changes to the moved file
> > without also clearing the conflict marker.
>
> But that's what we do with text conflicts if you postpone them. We
> modify the working file (with conflict markers), and leave the
> conflict in place.
No. The conflict markers are already there when the resolver runs!
They are the result of a diff3 merge performed during the update.
Re: Automatic tree conflicts resolution during svn update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
>> I'd say, just edit the moved file with the incoming content, embedded
>> in conflict markers, just like what we do for text conflicts. That, I
>> think, would be as good as possible.
>
> That's basically what updating the move is doing anyway.
> I wouldn't want to apply the incoming changes to the moved file
> without also clearing the conflict marker.
But that's what we do with text conflicts if you postpone them. We
modify the working file (with conflict markers), and leave the
conflict in place. So why not do this in this case? The incoming
content is embedded in conflict markers.
Something like this:
moved-file.txt:
blah
<<<<<<< .mine
=======
incoming line 1
incoming line 2
>>>>>>> .r2
the end
--
Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
> I'd say, just edit the moved file with the incoming content, embedded
> in conflict markers, just like what we do for text conflicts. That, I
> think, would be as good as possible.
That's basically what updating the move is doing anyway.
I wouldn't want to apply the incoming changes to the moved file
without also clearing the conflict marker.
Re: Automatic tree conflicts resolution during svn update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jun 12, 2013 at 3:25 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jun 12, 2013 at 03:04:56PM +0200, Johan Corveleyn wrote:
>> Okay, but doesn't "postpone" still needs to have a well defined
>> behavior (and probably "as good as possible"), even if only for
>> supporting the --accept=postpone command line option?
>
> What is "as good as possible"?
>
> The --accept postpone option (or equivalent menu option) simply
> leaves the conflicted node as-is. I don't think we can make the
> incoming edit visible without updating the moved file.
I'd say, just edit the moved file with the incoming content, embedded
in conflict markers, just like what we do for text conflicts. That, I
think, would be as good as possible.
--
Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 12, 2013 at 03:04:56PM +0200, Johan Corveleyn wrote:
> Okay, but doesn't "postpone" still needs to have a well defined
> behavior (and probably "as good as possible"), even if only for
> supporting the --accept=postpone command line option?
What is "as good as possible"?
The --accept postpone option (or equivalent menu option) simply
leaves the conflicted node as-is. I don't think we can make the
incoming edit visible without updating the moved file.
Re: Automatic tree conflicts resolution during svn update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jun 12, 2013 at 1:57 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jun 12, 2013 at 01:34:37PM +0200, Johan Corveleyn wrote:
>> Can't we improve this? (not talking about emergency fixing 1.8.x, but
>> thinking longer term). Can't we put the incoming edits "somewhere", so
>> the user can do something useful (manually) with them? Perhaps put
>> them in the moved-file with conflict markers around them, like we do
>> for text conflicts?
>
> I believe that in the future we'll just update the moved-away files
> by default, without even asking the user. This way, the edit shows
> up in the moved-away file, just as it does now if the user chooses
> 'mine-conflict' at the prompt.
Okay, but doesn't "postpone" still needs to have a well defined
behavior (and probably "as good as possible"), even if only for
supporting the --accept=postpone command line option?
--
Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 12, 2013 at 01:34:37PM +0200, Johan Corveleyn wrote:
> Can't we improve this? (not talking about emergency fixing 1.8.x, but
> thinking longer term). Can't we put the incoming edits "somewhere", so
> the user can do something useful (manually) with them? Perhaps put
> them in the moved-file with conflict markers around them, like we do
> for text conflicts?
I believe that in the future we'll just update the moved-away files
by default, without even asking the user. This way, the edit shows
up in the moved-away file, just as it does now if the user chooses
'mine-conflict' at the prompt.
To do that properly, we need better conflict resolution APIs that we
don't have in 1.8 yet. Right now, the API does not communicate to
consumers which of the available options trigger an automatic resolution
and which don't. I'd rather avoid the situation where API users start
making assumptions about the effects a particular conflict choice will
have. I'd rather communicate a 'automatic resolution' choice to clients
at the API level.
Re: Automatic tree conflicts resolution during svn update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jun 12, 2013 at 12:59 PM, Danil Shopyrin <da...@visualsvn.com> wrote:
> On Tue, Jun 11, 2013 at 4:12 PM, Stefan Sperling <st...@elego.de> wrote:
>> 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?
>
> The new prompt menu makes a great improvement. The most important part
> is that 'apply edit' action is marked as 'recommended'.
>
> But is it possible to make the solution even better and apply edits
> automatically without prompting users?
>
> Also I agree with the idea that this case is not a real "tree
> conflict" (from the user's point of view). The real "tree conflict" is
> when user renames 'Program.cs' to 'SuperProgram.cs' while the file is
> already renamed to 'MegaProgram.cs' in the repository. The discussed
> use case is much simpler and it's not treated as a conflict by most of
> the users.
>
> So I propose to apply edits automatically to all files renamed in the
> working copy (except the possible edge cases, of course). Users who
> don't want edits to be applied automatically can run 'svn update' with
> the '--accept=postpone' option. But I expect that most of the users
> will be happy with the automatic behavior.
Just to summarize a discussion we just had here in Berlin: the
"postpone" option in this case is not symmetrical with postponing text
conflicts.
Postponing text conflicts leaves both sides available in your working
file, for you to edit manually and resolve any way you see fit.
If you postpone a "localmove-incomingedit" conflict, there is no trace
of the incoming edit in your working file, so it's much harder to do
something manually with it. The incoming edits are sort of present, in
the base file of your moved-away (deleted) node, but that's a bit hard
to discover and to access for the user (not to mention, if he opens
delete-file@BASE he can't discern what was part of the incoming edit).
I think the non-symmetry of postpone is a bit confusing, but more
importantly, I think this makes postpone not a very good option.
Can't we improve this? (not talking about emergency fixing 1.8.x, but
thinking longer term). Can't we put the incoming edits "somewhere", so
the user can do something useful (manually) with them? Perhaps put
them in the moved-file with conflict markers around them, like we do
for text conflicts?
--
Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Danil Shopyrin <da...@visualsvn.com>.
On Tue, Jun 11, 2013 at 4:12 PM, Stefan Sperling <st...@elego.de> wrote:
> 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?
The new prompt menu makes a great improvement. The most important part
is that 'apply edit' action is marked as 'recommended'.
But is it possible to make the solution even better and apply edits
automatically without prompting users?
Also I agree with the idea that this case is not a real "tree
conflict" (from the user's point of view). The real "tree conflict" is
when user renames 'Program.cs' to 'SuperProgram.cs' while the file is
already renamed to 'MegaProgram.cs' in the repository. The discussed
use case is much simpler and it's not treated as a conflict by most of
the users.
So I propose to apply edits automatically to all files renamed in the
working copy (except the possible edge cases, of course). Users who
don't want edits to be applied automatically can run 'svn update' with
the '--accept=postpone' option. But I expect that most of the users
will be happy with the automatic behavior.
--
With best regards,
Danil Shopyrin
VisualSVN Team
RE: Automatic tree conflicts resolution during svn update
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@wandisco.com]
> Sent: woensdag 12 juni 2013 16:13
> To: dev@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@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:julianfoad@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@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 <st...@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@wandisco.com
Re: Automatic tree conflicts resolution during svn update
Posted by Branko Čibej <br...@wandisco.com>.
On 12.06.2013 15:42, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane@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:julianfoad@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@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 <st...@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. brane@wandisco.com
RE: Automatic tree conflicts resolution during svn update
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@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:julianfoad@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@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 <st...@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. brane@wandisco.com
Re: Automatic tree conflicts resolution during svn update
Posted by Branko Čibej <br...@wandisco.com>.
On 12.06.2013 08:47, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Julian Foad [mailto:julianfoad@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@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 <st...@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. brane@wandisco.com
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 12, 2013 at 08:47:32AM +0200, Bert Huijben wrote:
> 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
Yes, that's correct.
The original text said 'apply update', not 'apply edit'. Ivan said
that 'apply edit' is clearer, but perhaps it is also confusing?
Should we say 'apply update' instead of 'apply edit'?
> The other option is updating the move target, to make it match the new
> moved-from revision.
And we have special notifications to signal when a move is broken, too.
RE: Automatic tree conflicts resolution during svn update
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Julian Foad [mailto:julianfoad@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@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 <st...@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
Re: Automatic tree conflicts resolution during svn update
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/12/2013 12:28 AM, Julian Foad wrote:
>>> > 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?
[...]
>> 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.
I'm gotta say, I'm wondering about this, too.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Automatic tree conflicts resolution during svn update
Posted by Julian Foad <ju...@btopenworld.com>.
Bert Huijben wrote:
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel@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 <st...@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.
- Julian
RE: Automatic tree conflicts resolution during svn update
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@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 <st...@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?
The copy/add part would be of a different revision than the delete part of
the move if you don't apply the move.
Bert
>
> --
> Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jun 11, 2013 at 4:27 PM, Stefan Sperling <st...@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?
--
Johan
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
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),
(p) postpone, (q) quit resolution, (h) help: h
(mc) - apply incoming edit to move destination [mine-conflict]
(r) - discard edit, mark resolved, the move will become a copy
(p) - resolve the conflict later [postpone]
(q) - postpone all remaining conflicts
(h) - show this help (also '?')
Words in square brackets are the corresponding --accept option arguments.
Select: (mc) apply edit (recommended), (r) discard edit (breaks move),
(p) postpone, (q) quit resolution, (h) help: mc
U alpha2
Updated to revision 3.
Resolved conflicted state of 'alpha'
Summary of conflicts:
Tree conflicts: 0 remaining (and 1 already resolved)
$
Re: Automatic tree conflicts resolution during svn update
Posted by Prabhu <pr...@collab.net>.
On 06/11/2013 05:42 PM, 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?
when we say, "svn update, svn switch, and svn resolve can now
'automatically' resolve
tree conflicts involving locally moved files or directories.", one would
not expect to see a menu thrown in front of them (with trivial questions)..
What I would think of in this case is the "incoming edit" me applied
against the "local-move"d file and just say,
Resolved conflicted state of 'dir1/file1'
Summary of conflicts:
Tree conflicts: 0 remaining (and 1 already resolved)
Just my thoughts.. Not sure if it makes sense with respect to our
current code.
--Prabhugs
Re: Automatic tree conflicts resolution during svn update
Posted by Stefan Sperling <st...@elego.de>.
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?