[MERGE] Enhance conflicts when OTHER deletes a needed directory

Martin Pool mbp at canonical.com
Wed Sep 6 05:03:06 BST 2006


On  5 Sep 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> The problem with conflict messages is that they try to be symmetrical.

Or in other words: messages will be more understandable if they
recognize that merges are not symmetrical.  The user model for merges is
"bring $that into $here".

> This works out rather badly when OTHER tries to delete a file, and THIS
> has added files to it.  You get:
> "Conflict adding files to foo.  Not deleting."  "Conflict adding files"
> would make sense in the other direction, i.e. merging THIS into OTHER.
> But merging OTHER into THIS, the problem is deleting a directory without
> deleting all its children.
> 
> This patch changes the message to "Conflict deleting parent directory
> foo because it has children.  Not deleting."
> 
> This fixes bug # 47764
> https://launchpad.net/products/bzr/+bug/47764

It looks like a good fix for that, so +1 as it stands.

I wonder if, while we're here, we can make the message even better.
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.

>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 ...

Rather than "has children" which is a bit abstract I would say "is not
empty".  Everyone knows what an empty directory is, but "children" has
many possible meanings.

(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.)

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.


-- 
Martin




More information about the bazaar mailing list