On Tue, Sep 06, 2005 at 10:17:32AM +0200, Thomas Haas wrote: > Although using monotone for a while, I cannot get used to easily read, > compare, and for sure not type monotone's revision identifiers. 40 bytes > of hex is too complicated for me. Also the rather long revision, > manifest and file identifiers use up a lot of precious real estate in > various outputs, such as ls, cat, or log.
Thanks, we really appreciate getting feedback on things like this. > RFC 1751 (http://www.faqs.org/rfcs/rfc1751.html) describes a method for > representing 128 bit keys as a list of English words. While easier to > read, RFC 1751 does not solve the problem of real estate. It's also rather rude to use such a language-specific list. See also: http://lists.gnu.org/archive/html/monotone-devel/2004-12/txtN5iN4PaFhU.txt > Using the alphabet (A-Z, a-z) and the ten digits would reduce the real > estate from 40 to 27 characters. > > Additionally, or alternatively, a different, persistent representation > of the various identifiers could ease the use of monotone. E.g. > revisions could be counted as in sub-version or monotone limit itself to > display identifiers as short as possible, while still unique (the result > could be fed into monotone complete to get the full identifier). We've previously resisted using truncated identifiers in the UI, because of a possible attack: 1) Alice, a well-known and trusted developer, says "Hey, everyone, rev abcdef fixes your problems, try it" 2) But Alice forgets to sync abcdef to the server! 3) Mallory notices hits, and inserts a security hole, and, since abcdef is only a few bits of hash, he spends a few minutes of computer time fiddling whitespace in his security hole back-and-forth so that its truncated hash is also abcdef. 4) Mallory sneaks this version onto the server somehow (perhaps he legitimately has push access, but because of his name no-one trusts his certs without review). He doesn't sign it. 5) Bob sees Alice's message, does a pull, checks out abcdef, and happily builds and runs it and gives it to all his friends, because Alice said it was awesome, and he trusts Alice. Because Alice forgot to actually push her version, he doesn't even get any warning about using an ambiguous prefix. On the other hand -- in practice, people often write truncated revision ids anyway, so it's arguable that this problem basically exists now. Truncated hashes also raise some mildly annoying issues -- what do you do if some joker _does_ generate a conflict, how do you present that? (just one hash in a table mysteriously being longer than the rest, I guess?) Does checking for ambiguity every time you write out a hash unduly impact performance? And so on... Truncated hashes do have the strong advantage over methods that they avoid introducing a new namespace, so that everyone has to constantly keep track of which namespace to use in which circumstance. > Personally, I would prefer some short, readable identifier valid only > for my database. What does "short, readable" mean? Is 1932 more readable than 7349c052? Or are you thinking of CVS/BK-style 23.2.17.8 type things? How would you expect the UI to work? In particular, how would you expect to match up local and global identifiers when necessary? Should output always include both? Is it possible you could give more details on exactly why you want these things? This is a very serious question; the more we know about how people are thinking about and planning to use features, the better we can do at designing them... is it just that you find 1932 easier to type than 73c9be, for instance? -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
