[Monotone-devel] Merging outside monotone?

[Wim Oudshoorn]

After using monotone for a while I am becoming of the opinion
that the current merging behaviour is not very user friendly.

The problems I have come down to three problems, in various
degrees of annoyances

1) The necessity of having a merge tool.

2) The fact that one mistake in merging can
   let you lose all merges upto that point.

3) The order of merging imposed by monotone.

I will first detail the 3 points above conclude
with a short description of an alternative 
way of handling to provoke a discussion.


1 - Need to have a merge tool
-----------------------------
This is a minor annoyance.  But I work
monotone on MS windows computers, and on those
machines it is not very customary to have one
of the default merge tools available.

This makes it slightly more complicated to start using
monotone, it is one more tool to install.  
Otherwise you could just copy the monotone executable
and start using it.  

Also finding a merge tool that handles source files and
binary files in a good way is difficult and configuring
monotone to use different merging algorithms depending
on the file I have not dared to attempt yet.

2 - Merge mistakes loses merges already done
---------------------------------------------
If you are in a big project and have a complicated merge
and halfway you forget to save your merged file and exit
the merge tool monotone will see that you have not merged
that file and revert all files.  
This means that all the merges you had performed you have 
to do again.  
This is quite annoying.

3 - Order of merging
--------------------
Monotone forces you to merge all the files one by one
in an order imposed by monotone.  
But sometimes (quite often) in cases of a conflict
you want to see in which files there are conflicts and
examine the 'important' files first. 
Also I am not always merging in a linear fashion.  


Brainstorm section of an alternative
------------------------------------
DISCLAIMER:  I just thought this up, so
             it could well be that this is
             nonsense.

If instead of the current mechanism it would
be possible to have something like:

   monotone --merge-command=directory-dump merge

which will write out all the conflicts in a directory
structure like:

TEMP/Ancestor/file-1
TEMP/Ancestor/file-2

TEMP/Left/file-1
TEMP/Left/file-2

TEMP/Right/file-1
TEMP/Right/file-2

TEMP/Merged/file-1
TEMP/Merged/file-2

Now the user can use its favorite merge tool on these directories
and after the user is done do something like:

    monotone --merge-command=directory-input merge


Of course monotone in this case will check that the content
of the directory makes sense, so it probably needs to:

* Check by reading a file in the TEMP directory that
  the revisions of Left and Right and Ancestor makes sense 
  in the database
 
* The Merge directory indeed resolves all conflicts.  That
  is, the user has put a file there for all the files 
  need resolution.

If one of the conditions is wrong, monotone complains and
let the user fix the problem.


Wrapper tools integration
-------------------------
Another reason I would like such a structure is the fact
that I am writing a pclcvs like emacs mode for monotone.
I would prefere to do my merging in this mode as well.
For this it would be nice if I could have such
a directory structure and present the user with
tools to merge the files one by one and commit the merge
result in the end. 
With the current behaviour I don't see how I could accomplish
that.

Wim Oudshoorn.