On Mon, Apr 06, 2015 at 08:54:20AM -0600, Warren Block wrote:
> May I humbly request improvements for this error message?
>
> local dir edit, incoming dir delete upon update
>
> The ambiguity of "edit" and "delete" (whether adjectives or verbs) is
> confusing every time.
>
> Could it be:
>
> local dir has been modified, but dir has been deleted in repository
>
> Or something like that.
>
> Thanks!
Hi Warren,
Are you simply asking for the wording to change? Or are you asking
for a more precise description of how the tree conflict came about?
The degree of ambiguity goes much further than one might expect.
Most tree conflict messages are very terse and usually fail to describe
the actual conflict situation in an adequate fashion. Currently it's up
to the user to figure out what really happened. The message provides a
small hint based on the information available to the client at the time
the conflict was recorded. More often than not it lacks sufficient detail.
'edit' was chosen to describe local changes that occurred somewhere at
or within a directory. These changes may be "local" to a branch (in case
of merge) or a working copy (in case of merge or update).
The client does not always know what the local changes are. E.g. in case
changes happened in the history of a branch it currently does not know
much about them, since conflict recording does not take history of the
merge target into account. Only the tree configuration resulting from
the local changes is known.
Perhaps 'modification' would be a better term than 'edit'. But I don't
see how such a small change in wording alone provides a huge improvement.
As I see it, the situation as a whole could be vastly improved by providing
more information to the client, or trying to make the client get at more
information, so the conflict can be described to the user in more detail.
FWIW, Subversion 1.9 describes your tree conflict as follows, hinting at
the possibility that the incoming delete could also be an incoming move
(perhaps causing more confusion for users, or perhaps not :-)
> local dir edit, incoming dir delete or move upon update
I think that, ideally, SVN should show something like this (I'm making
up a conflict description and some possible resolution options -- there
could be other options users might want):
Tree conflict while merging r4242 from
'^/trunk'
into
'^/branches/5.4.x@5100'
with common ancestor '^/trunk@4180':
'harry' removed directory '^/trunk/foo' in r4242
'sally' edited '^/branches/5.4.x/foo/README.txt' in r5003
'bob' edited '^/branches/5.4.x/foo/src/common.c' in r5010
'alice' edited svn:ignore on '^/branches/5.4.x/foo' in r5013
More local changes present but not shown. To see all local changes, use:
svn log -r 4180:4242 ^/branches/5.4.x/foo@5100
Select: (p) postpone, (q) quit resolution, (h) help,
(k) keep local directory 'foo' as-is
(d) accept the deletion directory 'foo' discarding all local changes
(m) move 'branches/5.4.x/foo' to a different path
Some of these improvements could already be made today. But we've been
waiting for advances in server-side move tracking before making additional
changes to the conflict menu and the underlying APIs which support it.
Server-side move tracking is being researched but there is no solution
ready to be part of a future release yet. Note how an incoming move would
affect our idealized conflict description and set of resolution options:
'harry' moved directory '^/trunk/foo' to '^/trunk/bar' in r4242
'sally' edited '^/branches/5.4.x/foo/README.txt' in r5003
'bob' edited '^/branches/5.4.x/foo/src/common.c' in r5010
'alice' edited svn:ignore on '^/branches/5.4.x/foo' in r5013
More local changes present but not shown. To see all local changes, run:
svn log -r 4180:4242 ^/branches/5.4.x/foo@5100
Select: (p) postpone, (q) quit resolution, (h) help,
(k) keep local directory 'foo' as-is
(m) rename local foo to bar and merge any outstanding differences
between incoming bar and local bar
