bookmarks extension

Mads Kiilerich mads at kiilerich.com
Tue Mar 3 14:36:03 CST 2009


Frank Kingswood wrote, On 03/02/2009 03:01 PM:
> Hallo!
>
> I notice that the output from hg bookmarks has a format that is more 
> difficult to parse by scripts than necessary.
> The current format is
>
> [space] [space or *] [space] [padded bookmarkname] [revision]
>
> This is in contrast with for example hg tags which returns
>
> [padded tagname] [revision] [optional space and type]
>
> and I note that hg id has another format again
>
> [revision] [optional *] [name]
>
> The output from hg id and hg tags can be parsed unambiguously, but 
> unfortunately not that from hg bookmarks.
>
> The leading space in bookmarks makes splitting on fields needlessly 
> different between different languages: Python str.split() ignores 
> leading whitespace but Tcl split makes it into an empty field.
>
> The optional * should ideally be at the end of the line, so that the 
> other fields do not change their index when it is present.
>   

Can you explain why this particular format is so difficult to parse?

Yes, you can't use line.split(), but you can use line[1]. I am sure Tcl 
has similar functionality. split() is always dangerous to use when 
filenames and labels can contain whitespace.

Having a field at a fixed position and with a fixed size is unambiguous 
and simple. Optional fields are often less simple and more error prone. 
And putting optional fields at the end of the line doesn't scale.

The output of "hg tags" can be parsed unambigously, but not with a 
simple split. It must done backwards, considering that it is possible to do
hg tag '* tip                              3 2dcc578f5238'

And AFAICS the output of "hg id -t" cannot be parsed unambiguously at all.

/Mads

ps: If I had a need for parsing Mercurials output then I would request 
something like Marshalled Python output 
(http://kb.perforce.com/ToolsScripts/PerforceUtilities/UsingP4G) (or 
JSON or XML or whatever).  And hope that it wouldn't be rejected because 
it looked like a license loop-hole.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3435 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090303/5ddcbc1e/attachment.bin 


More information about the Mercurial-devel mailing list