[Monotone-devel] Re: Proposal for human readable revision IDs

[Bruce Stephens]

Andy Jones <address@hidden> writes:

>> I remain a bit sceptical that a 27
>> arbitrary character sequence composed of upper and lower letters and
>> digits (excluding a few) would actually be more readable (in any
>> useful way) than a 40 digit sequence of hex digits.
>
> +I+ would find it easier.
>
> If you are unsure, test it out - see how long a string of letters
> the people around you can remember, and how long a string of hex
> numbers.  Or just ask them which they think they would find easier.

I'm not sure about 27 characters, but I just hacked something to
produce 14 character strings from an alphabet of 60 characters (I
think that's about right, isn't it?), and yes, that's much better.  An
example is "tw7535wMJBCH0U" (the alphabet is upper and lower case
letters and digits, with O and l removed).

On the other hand, why do I want the hash to be readable?

I don't want to be able to remember a hash to type it somewhere else,
because I'll just cut and paste.  

Comparing for equality is one application (and as you suggest,
breaking up whatever the string is would help for that, although I
fear it would make cut and paste less convenient, at least some of the
time, unless there's some suitable character that's always regarded as
a word-constituent (underscore comes close, I guess)).

Other reasons for some kind of improved id would include seeing the
relationship between two hashes (are they on the same branch, are they
by the same author, is one before the other), being able to construct
variants of the id (if I know a CVS revision, then I can guess the
predecessor and successor), or more directly seeing details of the
revision (its date, branch, author, etc.).

Using a larger alphabet doesn't (that I can see) help any of those: it
potentially lets you remember one while you type it somewhere else,
and it makes it easier to see matches between hashes.

[...]