[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: user-friendly hash formats, redux
From: |
Brian P. Campbell |
Subject: |
Re: [Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Thu, 9 Dec 2004 20:18:27 -0500 |
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.
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Jonathan Matthew, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/11
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Patrick Mauritz, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux,
Brian P. Campbell <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/10
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Matthew A. Nicholson, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Phil de Joux, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Patrick Mauritz, 2004/12/10