Re: [Monotone-devel] nvm.resolve_conflicts ready to land on mainline

[Stephen Leake]

Tero Koskinen <address@hidden> writes:

> On Sat, 01 Nov 2008 12:26:21 -0400 Stephen Leake wrote:
>
>> I believe nvm.resolve_conflicts is ready to land on mainline.
>
> I briefly looked at nvm.resolve_conflicts. 

Thanks for looking at this.

> A few comments:
>
> * Builds and all tests pass on OpenBSD/i386.

good.

> * Documentation looks nice. I was able to figure out
>   how to use the commands.

Thanks.

> * Code (cmd_conflicts.cc) was pretty easy to read and understand.

Thanks.

> However, it tooks quite a lot of commands to get
> two revisions with conflicts merged. 

Was it more comfortable than the standard "here's another file to
merge" approach?

> I would like to have some kind of simple interactive menu system
> instead of multiple commands. Perhaps something like what Darcs or
> mergemaster have.

Can you give an example of how the menus in those tools work? I don't
have them installed, and I'd rather not try to figure out how to use
them just for this.

No other commands in mtn present menus. I'm not inclined to start
adding that functionality. I prefer to add functionality in Gnu Emacs
DVC for a better interface to mtn conflicts.

> In addition, I found a bug from set_first_conflict function:
> when doing command "mtn conflicts resolve_first interactive",
> mtn crashes, because 
>   N(args.size() == 2, F("wrong number of arguments"));
> check is done after calling 
>   idx(args,1)())

Ok, I'll add tests for all the mtn conflicts commands for number of args.

> A patch below makes the interactive command to use the name
> of the conflicting file by default if no name is given.

There are two files, one from each revision. You arbitarily choose
the left, when the user might want the right one. I don't think it's a
good idea to default this.

> Ps. Code seems to have multiple over 110 characters long lines,
> does the Monotone coding standards say anything about maximum line
> length?

Not directly in HACKING (I searched for "length"). However, that
references the "Gnu coding standards", without a URL. A quick web
search found http://www.gnu.org/prep/standards/ . A quick look there
turned up no line length limit. But maybe I missed something.

I prefer a line length limit of 120; that encourages expressive
variable and function names (as opposed to obscure abbreviations),
fits easily on modern screens, and can be printed on paper nicely.

-- 
-- Stephe