[MERGE] Enhance conflicts when OTHER deletes a needed directory

[Aaron Bentley]

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

Martin Pool wrote:
> On  5 Sep 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> I wonder if, while we're here, we can make the message even better.

I would like to.

> Generally I think it looks good (and is consistent with pep8 and other
> style guides) if messages are either a single phrase *or* one or more
> proper sentences.  Multiple phrases are oddly stilted.  Should be
> avoided.

Okay, so here's what I'm trying to so.  Sentence one: describe problem.
 Sentence two: describe the actions taken.

>>From the user's point of view what has happened?  
> 
>   The merge source deleted directory $foo, but it is not empty in the 
>   destination.
> 
> or
>   
>   Merge wants to delete $foo, but...
> 
> or
>   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:

$ bzr init a
$ mkdir a/b
$ bzr add a
added b
$ touch a/b/c
$ bzr revert a
Conflict deleting parent directory b because it has children.  Not deleting.

> Rather than "has children" which is a bit abstract I would say "is not
> empty".

Fully agree.  Got lost in the internals a bit, I guess.

> (Incidentally does this conflict only happen if the children are
> versioned?  It seems like a similar conflict should happen if there are
> unversioned, un-ignored children, which is actually what Brad asked
> about in his bug.)

This conflict will also happen when there are unversioned children.  In
fact, these are separate steps:
- - if the directory is not empty, it will not be deleted
- - if some of its contents are versioned, it will not be unversioned.

So if it has only unversioned contents, it will not be deleted, but it
will be unversioned.

> It seems like for many conflicts there are several parameters we need to
> present:
> 
>   What happened in the other branch (e.g. "directory deleted")
>   What happened in this branch (e.g. "directory contains files")
>   What bzr did about it (e.g. "directory retained and conflicted")
>   What the user can do now ("delete the directory, or mark it resolved 
>       to keep it.")
> 
> Is this accurate for all conflicts?  Perhaps we should explicitly
> present them in this form to make it more clear?  The Conflict objects
> already go in this direction so basically I'm just proposing to make the
> formats more structured.

I like the direction, but I'm not sure about the specifics.  Not all
TreeTransforms involve other branches, so this doesn't really work for
revert conflicts.  We can address that by having separate conflict
resolvers for revert and merge, but at this point, it still feels like
the conflict resolution for both operations is very similar.

Another issue is that Merge3Merger and co. don't care about branches,
only trees.  So I start to feel like we should be raising exceptions and
letting bits of the code that are more user-facing handle the info.
Since doing that is impractical, maybe callbacks would work?

The TreeTransform itself can only tell us:
"I want perform action x, but that doesn't make sense, because of state
y."  From the details, we can usually determine which way the asymmetry
points.

A TreeTransform does include a WorkingTree, so we can determine the
state of that.  And if we desire, we can pass the OTHER into the
conflict resolver.  So I think we could do what you're suggesting for
merge, but I don't think we should make 'branch' parameters for conflict
types, because that's too merge-specific.

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.

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

iD8DBQFE/laS0F+nu1YWqI0RAlwmAJ9LJxl/8fAw/YKVL6XC1MRp58b+BgCfcP9D
fb5JG6BUQCRKF6kgBMMK7a8=
=kMc5
-----END PGP SIGNATURE-----