[MERGE] Enhance conflicts when OTHER deletes a needed directory

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On  6 Sep 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 
>>>  Can't delete $foo because ...
>>
>>I would be happiest with the last, because this conflict resolver is
>>used for revert as well as merge, and the other messages are specific to
>>merge.  This conflict, in particular, can happen when reverting:
> 

Based on your +1, I've submitted a version that says "Conflict: can't
delete directory foo because it is not empty."

The rest of this feels like a larger design update, so we shouldn't make
that change depend on these.

> OK, good point.  So the situation isn't symmetrical in that to the user
> there's a clear distinction between $this and $other, and they expect
> the message to be written that way.  But the message should be
> "reusable" because of the ways in which general merge is used.

I generally agree.  Another advantage of reusable messages is that
they're familiar when the user encounters them in other contexts.

I'm not sure if you're clear on this, but revert is no longer done using
merge, because it's a simpler case with sightly different behaviour.

>>Perhaps that's taking your suggestion too literally.  A more practical,
>>but less nice, option would be:
>>
>> * What the desired action was
>> * Why it couldn't be performed
>> * What Bazaar did about it
>> * What the user can do about it now.
>>
>>There are some tradeoffs here, because that's a lot of data per
>>conflict, and it could be overwhelming.  Only the last item looks like
>>it could be optional, though.
> 
> 
> That looks reasonable, and I think it can be made fairly nice.  Think of
> them like stepping stones with easy mental steps
>  
>   I asked bzr to merge from there
>   .. and that was going to delete this directory
>   .. but it's not empty
>   .. so now it's conflicted but still versioned
>   .. so what am I going to do?
> 
> The conflict perhaps doesn't need to give the first one because the user
> just asked for it.  So "delete $dir" isn't so much a desired (by the
> user) action, as the first consequence of what they asked for.

We can imply "Attempted to delete foo" by saying "Unable to delete foo
because it is not empty.".  Is that what you had in mind?

I think including the word "conflict" in all our conflict messages is a
good idea, because that will tip people off on how to get more help.

I'm having trouble phrasing the message for text conflicts.  Which is
the most common one.

"Some text changes to foo could not be automatically combined, because
different changes modify the same sections.  Conflict markers have been
placed in foo, and copies of the source files have been created, named
foo.THIS, foo.BASE and foo.OTHER.  Please edit foo to manually combine
the changes, and run 'resolve foo' when you are done."

Aaah!

This is starting to make me think conflicts should be emitted more like
status output:

- ---
Text conflicts occured in the following files:
  foo
  bar
  baz/qux
Some text changes to these files could not be automatically combined,
because different changes modify the same sections.  Conflict markers
have been placed in the files, and copies of the source files have been
created, with the extensions .THIS, .BASE and .OTHER.  Please edit each
file to manually combine the changes, and run 'resolve' when you are done.

Deletion conflicts occured in the following files:
- ---

> As you say this can be quite long, so I think we could have an expert
> mode (bzr conflicts --short?) where it just gives a terse description,
> something like "DeletedParent/ContainsUnknowns/Unversioned", or maybe
> even shorter.

Yes, we can do something like this.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFE/s2p0F+nu1YWqI0RAl97AJ4l0lc3zHqJ5QMuV//LWMmbUvWN0ACfQ6Q0
yOYwcg39XHyXIgZPsBqQfSs=
=lILS
-----END PGP SIGNATURE-----