Re: [Monotone-devel] Re: user-friendly hash formats, redux

[Brian P. Campbell]

I've been following this discussion on friendlier ways of representing 
revisions, and I'd just like to add my own two cents. I should add the 
caveat that I've never used monotone for any real projects, so I don't 
actually know how well certain things work, but this is what I think of 
the various ideas.

I don't like the bibblebabble or TLW suggestions. I think that, as 
Graydon says, they look kind of crazy, and aren't really memorable 
enough to be worth making monotone even more strange. I think one thing 
that would help a lot is to make the hex identifiers monotone prints be 
shorter. '3b12b2d0b31439bd50976633db1895cff8b19da0' is a lot more scary 
than '3b12'. I think that shorter hash prefixes like that are actually 
perfectly manageable, much more so than "JimBowHunTogFoo". If monotone 
would print 3b12 instead of the full string, that would be less 
intimidating to users, easier to deal with, and fix most of the things 
that the bibblebabble type suggestions deal with. There remains the 
question of how to choose how much of the prefex to print.

Some people have suggested automatically determining how many to print 
based on the minimum number needed to uniquely identify any item in the 
database. This would provide the shortest possible output, although for 
small projects at first, it could cause problems, because two people 
might only get two digits worth of output, which collide when they try 
and talk to each other. It might be better to divide it into chunks of 
4 hex digits, and print out as many of those chunks as necessary. Two 
of those chunks should probably be enough for most repositories, and 3 
should be enough for anything but massively huge repositories 
(according to some hasty and probably not very accurate calculations, 
12 hex digits gets you a 99.9% chance of having no collisions between 1 
million identifiers). I think that it wouldn't be too bad to see and 
type something like 3b12.b2d0 or even 2650.ffc6.60dd. Since 8 digits 
should be enough for most purposes, and people memorize and recite 7 
digit phone numbers (in the US) all the time, I think it sounds pretty 
reasonable.

As far as all of the proposals for stable, meaningful, cross database 
identifiers, all of the proposals so far seem fairly cumbersome, and 
change or conflict with fairly large parts of monotone's architecture. 
Once you start talking about branch.author.seq#, you might as well just 
use the selectors that are already built in. I think the current set of 
selectors could be enhanced a little. For instance, various people have 
discussed adding +n or -n for walking up and down the tree, which I 
think is a great idea. Also, it would be nice if there were some really 
easy way of adding a tag to a revision as you were checking it in. Then 
you could use the tag selector to get different revisions. Perhaps when 
you do a commit, some specially delimited portion of the log message 
could be considered a tag. Or maybe you could just add matching against 
log messages to the set of selectors. But having something descriptive 
that you can match against using the selectors, and can apply when 
doing a commit, would be nice. Finally, I think the default date format 
should be changed. "T" just isn't a good delimiter; I can't immediately 
scan it and see the separation between date and time. I realize that 
that is an ISO standard, but I don't think it's a very good one. Using 
just a space would make it much easier to read, but really any standard 
delimiter character would work better than a "T". I find it hard to use 
date and time stamps in specifiers because when I'm looking at a 
date/time that has been printed out as part of a certificate, I can't 
really parse it easily.

Also, as far as easy parsing, the current format that certificates are 
printed out in makes them hard to read. There's just too much junk on 
the screen. I think that easily being able to read the certificates 
will also help selectors be more useful, since it will mean that people 
can refer to that information more easily. Something like this:

branch: co.jp.juicebot.jb7
date: 2004-10-26 02:53:08
author: address@hidden
changelog: initial checkin of project

Is much easier to read than:

     -----------------------------------------------------------------
     Key   : address@hidden
     Sig   : ok
     Name  : branch
     Value : co.jp.juicebot.jb7
     -----------------------------------------------------------------
     Key   : address@hidden
     Sig   : ok
     Name  : date
     Value : 2004-10-26T02:53:08
     -----------------------------------------------------------------
     Key   : address@hidden
     Sig   : ok
     Name  : author
     Value : address@hidden
     -----------------------------------------------------------------
     Key   : address@hidden
     Sig   : ok
     Name  : changelog
     Value : initial checkin of project

If you feel that including the key is really necessary, you could group 
all certificates signed by the same key together, and print it like 
this:

(address@hidden)
branch: co.jp.juicebot.jb7
date: 2004-10-26 02:53:08
author: address@hidden
changelog: initial checkin of project

(address@hidden)
branch: co.jp.juicebot.jb7

Anyhow, those are my suggestions for what should be done about the 
issue of large random hex strings being cumbersome to use. I think if 
you added these features, and edited the tutorial to use them, people 
wouldn't be nearly so scared, and it would make working with monotone 
easier.