a GUI front-end author's problems parsing mercurial output

[Matt Mackall]

On Fri, May 19, 2006 at 11:24:43AM -0700, Elliott Hughes wrote:
> hi. i'm the main author of the "SCM" front-end to Bazaar, BitKeeper,  
> CVS, Mercurial, and Subversion (http://software.jessies.org/scm/).  
> it's a Java/Ruby GUI that aims to give you a good revision control UI  
> regardless of your choice of revision control system or OS. i pushed  
> the preliminary Mercurial support last night (so anyone brave enough  
> to poke about with it is welcome to send us feedback, though off-list  
> because none of us are subscribed), and had a few comments i thought  
> you might be interested in, in roughly increasing order of importance:
> 
> * it's good that your command-line is broadly similar to bzr(1) and  
> svn(1), but it's a bit confusing that the wiki seems more up-to-date  
> than the commands themselves when it comes to what options they  
> support. it would be better if the in-command help text were  
> generated by the argument parsing code itself, for accuracy's sake.  
> (the most obvious example being "hg log -v", which works, is  
> necessary for my purposes, but which isn't mentioned in the "hg log -- 
> help" output.)

The help output is in fact generated from the argument parser, but -v
is a global option.

> * as far as i can tell, the character encoding is nowhere defined. i  
> haven't tested yet, but hopefully it's all UTF-8 internally? it would  
> be beneficial to tool authors if this were documented.

Currently there is no character encoding at all. Most everything is
8-bit transparent. But the intent has always been to use UTF-8 in the
relevant places, see:

http://www.selenic.com/mercurial/wiki/index.cgi/InternationalizationPlan
 
> * is there a reason why Mercurial doesn't use ISO date format (http:// 
> www.cl.cam.ac.uk/~mgk25/iso-time.html)? most modern tools do, but  
> Mercurial uses RFC-like dates that -- in the absence of a  
> specification -- always leave one wondering if those month names that  
> need parsing are going to trip us up one day on some system where  
> they're localized to a language other than English.

No, no reason.
 
> * the "files:" header line in the log output doesn't cope with  
> filenames containing spaces. there's no way to tell whether  
> "files:       new file" is one file or two. this could be solved by  
> escaping, URL encoding, or having multiple "files:" lines (like the  
> "parent:" lines); whatever's easiest in python.
> 
> * the "description:" in the log output doesn't escape check-in  
> comments containing "\n\n" or lines that look like header lines (so i  
> could have a comment "\n\nchangeset:    
> 2242:12e36dedf668c483df6fe0fbfb3f0efdaded8b4c\ndescription:\nthis is  
> a fake changeset!", say). a common solution to this problem is to  
> output each description line (and no other kind of line) preceded by  
> "  ". again, whatever's easiest in python is fine.

You might want to specify a custom log template, which can solve both
these problems.

-- 
Mathematics is the supreme nostalgia of our time.