[RFC] Conflicts handling in status command

Aaron Bentley aaron.bentley at utoronto.ca
Mon Jul 23 12:27:14 BST 2007


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

Guillermo Gonzalez wrote:
> Aaron Bentley wrote:
> 
> [snip]
>> The first column is reserved for +-R
>> (add/remove/rename).  Putting C there would interfere with that.  You'd
>> have to add another column.  Putting text after the filename would make
>> it hard for scripts to parse the output.
>>
> 
> I understand the problem with the first column (+-R), is there any problem
> to add a new column?

Just the desire to keep things simple.  It's not an absolute rule,
obviously.

> About the text after the filename, the conflicts are showed as "text
> conflict in <filename>". 

Actually, there are eight kinds of conflicts.

Single-path conflicts
=====================
text conflict
contents conflict
parent loop
unversioned parent
missing parent
deleting parent

Multi-path conflicts
=====================
duplicate id
duplicate filename

> Following the same pattern the proposed output could be modified to
> something like:
>  M C COPYING has text conflicts

- - Multiple conflicts may appy to a single file.
- - The multi-path conflicts don't fit your template at all.
- - If the file has been renamed, it's easy to see how you could run out
of space.
- - As I noted before, it makes it significantly harder for scripts to
parse the output.

> What other posibilities do you see? 
> (I'ld really like to know if this can be done)

I don't think what you're proposing makes sense.

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

iD8DBQFGpJCB0F+nu1YWqI0RAsuvAJ9oMYO1g4V4VLUOTi7sqX9W7qAzJACfRcdD
WL8JkyIFmpPh1k8cTqSJvIw=
=TNJo
-----END PGP SIGNATURE-----



More information about the bazaar mailing list