Re: [Monotone-devel] conflicts store vs show_conflicts

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 20.11.10 17:19, schrieb Stephen Leake:
>> As issue 108 pointed out, it might be good to move 'mtn show_conflicts'
>> to be part of the 'mtn conflicts' command group, so it is described by
>> 'mtn help conflicts'.
>> 
>> In addition, I need 'mtn au conflicts store' for Emacs DVC. There is 'au
>> show_conflicts', but that turned out to not be useful for DVC; does
>> guitone (or anything else) use it?.
>
> No, I'm not using the conflicts machinery until now. I should probably
> implement it sometime though...

Ok.

>> So I propose:
>> 
>> 1) add  'mtn conflicts show_all'; same behavior as 'mtn show_conflicts'.
>> 
>>     keep 'mtn show_conflicts' (with an alias if possible), but deprecate
>>     it. 
>
> I'm not sure if you can alias a normal to a subcommand, but if it works
> out, this is just fine.

Ok.

>> 2) add 'mtn au conflicts store'
>> 
>> 3) delete 'mtn au show_conflicts'
>
> ...and this is not replaced by anything? Because just storing the
> conflicts in basicio to a file without outputting them might get
> cumbersome for remote access 

Good point.

> (this is just theoretical, even if we do not have a "merge" or
> "propagate" command in automate right now...).

I'm heading in that direction :).

> In any case, please implement something in a way which does not require
> a major automate version bump, 

Deleting au show_conflicts would be a backward incompatible change. So
we'll just keep it.

> remember we communicated that 1.0 will be 0.99 + bug fixes, i.e. no
> new features or breakage. If this is not possible, please do it in a
> separate branch and we'll merge that for 1.1.

I think 'mtn au conflicts store' is more of a polishing than a new
feature? But I don't mind holding it for 1.1.

-- 
-- Stephe