[RFC] "short" revision id spec.

John Arbash Meinel john at arbash-meinel.com
Wed Apr 11 03:40:25 BST 2007


http://bzr.arbash-meinel.com/plugins/short_revid_spec

I just wrote a plugin to implement a pattern matching on revision-id
spec. Basically, it allows you to write a snippet of most revision ids,
and have bzr do the hard work of matching to a real revision id.

I wrote this because I was using graphviz to graph file histories, and
it makes it a lot easier if you can show only part of the revision id so
the nodes don't get too wide. But then I needed a way to find the commit
logs, etc.

I'm happy enough with how it works, though I'm not sure about the naming.

Basically, I'm using:

  -r srevid:[prefix--]suffix

And a short form:
  -r r:[prefix--]suffix

So you can do things like:

  -r r:john--c6498

or
  -r r:ae948

For bzr.dev there seems to be enough entropy that you only really need
to supply 4 characters (often 2 or 3 is enough).

So I have a few questions about the spec:

1) Is it reasonable to merge this into bzr.dev? I think it is generally
useful, but I wanted to play with it a bit first.

2) I don't really like 'srevid:' and grabbing 'r:' seemed a little bit
greedy. I'm okay with it in a plugin, because plugins let you do things
like be greedy. Because it doesn't have to work for everyone everywhere.
Any thoughts on what the prefix should be?

It might be possible to implement this, such that we don't even need a
prefix (it would work as a catch-all). But I would rather not do that yet.

3) r:x--y versus r:x-y or other forms. I chose -- because I prefer the
look of it. The single dash looked like I was actually trying to match
part of the revision id, rather than only trying to match the prefix and
suffix.

Obviously the real matching power is only in the suffix. The reason I
write them as prefix--suffix, is because that gives me the human being a
bit more of a handle on the object. It works better in graphing, because
I can associate 'that revision was committed by Aaron', even though the
committer doesn't really matter, it works better than "ae948".

Actually, my favorite "short" form is: user-date-hash. So my graphs use:

  john-20050918-c6498
  robertc-20050919-51340

That makes them reasonably short, and they have just enough information
for me to be able to latch onto them, and still be very unique.

It would be possible to update my form to support that sort of thing,
but that would sort of mean interpreting the revision ids, and not all
revision ids follow this form.

Note that another problem with '--' is that it fails on Arch converted
revision ids. Since 'patch-19' is not unique enough and so you have to
start tapping into the category--branch--version--patchlevel.


Anyway, feedback is appreciated, as I'm curious how to take this from
something which is useful to me, and making it generally useful.

John
=:->



More information about the bazaar mailing list