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

[Tero Koskinen]

Hi,

On Sat, 08 Nov 2008 14:25:55 -0500 Stephen Leake wrote:
> Tero Koskinen <address@hidden> writes:
> > 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?

Yes. The conflicts command set is definately an improvement over
the current situation.

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

Darcs' UI follows form:
 info
 rmat
 ion
Question? [snoitpn]:

For example:
**snip**
$ darcs record
hunk ./index.html 13
-<div class="innerContainer">
-
Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
What is the patch name? Remove extra div
Do you want to add a long comment? [yn]n
Finished recording patch 'Remove extra div'
$
**snip**

And mergemaster:
 info
 rmat
 ion

 [1] option 1
 [2] option 2
 [3] option 3

Question?

Example:
**snip**
===> Displaying differences between ./etc/changelist and installed
version:

--- /etc/changelist     Sun Aug 31 11:54:38 2008
+++ ./etc/changelist    Sat Nov  1 20:41:12 2008
@@ -1,4 +1,4 @@
-#      $OpenBSD: changelist,v 1.58 2008/06/13 00:46:57 ajacoutot Exp $
+#      $OpenBSD: changelist,v 1.59 2008/10/02 07:27:57 sthen Exp $
 #
 # List of files which the security script backs up and checks
 # for modifications.
@@ -152,6 +152,10 @@
 /var/cron/tabs/root
 /var/named/etc/named.conf
+/var/named/etc/rndc.key
+/var/named/etc/root.hint
+/var/named/standard/localhost
+/var/named/standard/loopback
+/var/named/standard/loopback6.arpa
 /var/www/conf/access.conf
 /var/www/conf/httpd.conf
 /var/www/conf/mime.types

  Use 'd' to delete the temporary ./etc/changelist
  Use 'i' to install the temporary ./etc/changelist
  Use 'm' to merge the temporary and installed versions
  Use 'v' to view the diff results again

  Default is to leave the temporary file to deal with by hand

How should I deal with this? [Leave it for later]
**snip**

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

Yeah, monotone doesn't have menu-based commands, but I still I would
like to see this conflict resolution logic refactored into a one. :)
(The asyncronous commands can also stay for editor/IDE integration.)

Ideally, something like "mtn merge --interactive" would start
the conflict resolution menu system.

An example of interactive merge could be something like this:
$ mtn explicit_merge --interactive c564266d6f0... 057862d149f09a4...
mtn: [left]  c564266d6f0ec9d2591ca4b5052cfd531e047330
mtn: [right] 057862d149f09a4b288a30f854c04f79e2922940
mtn: content conflict in test/tester.adb
mtn: possible resolutions:
mtn: [1] resolve_first interactive "file_name"
mtn: [2] resolve_first user "file_name"
mtn: How to resolve this conflict? 2
mtn: What is the file name? test/tester.adb
mtn: executing external editor "vim" for file "test/tester.adb"
mtn: all conflicts resolved
mtn: replacing content of test/tester.adb, test/tester.adb with test/tester.adb
mtn: [merged] 3f2ef9d43da99d96c21779abd6f9a79354dab126
$

(Using *exactly* this kind of ui/sequence might not make
 sense, but I assume one can get the idea).

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

My main point was that "mtn conflicts resolve_first interactive" should
not need the filename as its parameter. Instead, monotone can
generate the filename for the command. Probably randomly generated name is
better than the name from the left side.

> > 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 also read HACKING and GNU coding standards and found nothing.

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

For side-by-side merges the limit of 120 gives some headache. Also,
some people might use small laptops (like Asus EeePC) which don't have
big screens. Personally, I like to limit my lines to 80 characters,
but monotone code already has lines longer than that, so I won't
suggest it. :)

-- 
Tero Koskinen <address@hidden>