[RFC] two improvements to mercurial

Bryan O'Sullivan bos at serpentine.com
Mon Aug 29 20:26:11 CDT 2005

On Mon, 2005-08-29 at 19:34 -0500, Jordan Breeding wrote:

> 1) I don't quite know how to accomplish this one but it would be nice  
> to use opendiff/FileMerge.app as a merge tool on OS X.

Take a look at the hgmerge script, which already knows how to invoke
several different merge tools.  I haven't used FileMerge, but it should
be easy to teach hgmerge how to use it.

> This is okay so far as I know  
> how to test for opendiff and use it, the problem come in that  
> opendiff seems to exit immediately with a return code of 0 as long as  
> it could launch FileMerge.

That's a problem.  Perhaps you can script something up that waits for
the spawned FileMerge to exit.  This something will need to exit with
non-zero status if FileMerge fails or doesn't complete a merge.

By the way, there's a binary of kdiff3 available for the Mac.  You
should give it a try; it appears to be much better than FileMerge.

> 2) The other idea I have I am going to start implementing within the  
> next week or two.  The idea is to have better support for converting  
> cvs to mercurial.  Currently one can try to use tailor but I have not  
> had the greatest experience while trying to get tailor 0.99 working.

You should talk to Lele Gaifax about that, then; he's often on #tailor
on irc.freenode.net, and there's a tailor mailing list, too.  He's very
responsive and helpful.

> If 2) is  
> worthwhile then I will start on it as soon as I can.

I think that #2 is of dubious value.  If you help Lele by sending bug
reports or fixes for tailor, then more SCM users benefit than if you
hack git-cvsimport-script to work with Mercurial.

The ne plus ultra of CVS importers appears to be Subversion's.  A thing
of great value would probably be to adapt that into tailor, so that it
could parse CVS files directly with local access to the CVS root.  This
would speed up the import process by several orders of magnitude.

In a similar vein, adapting tailor so that it uses the Mercurial APIs
directly to perform commits, instead of forking for every commit, would
also speed imports up a lot, and would benefit people migrating from
other SCMs.


More information about the Mercurial mailing list