On Wed, Jun 12, 2013 at 12:59 PM, Danil Shopyrin <danil_at_visualsvn.com> wrote:
> On Tue, Jun 11, 2013 at 4:12 PM, Stefan Sperling <stsp_at_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_at_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
Received on 2013-06-12 13:35:33 CEST