monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Oren Ben-Kiki
Subject: Re: [Monotone-devel] Re: user-friendly hash formats, redux
Date: Thu, 9 Dec 2004 20:37:26 +0200
User-agent: KMail/1.7.1

On Thursday 09 December 2004 17:11, Nathan Myers wrote:
> If somebody has a dozen independent programs in a repository, with
> nothing in common between them, they will be confused if you insist
> that they are "branches".

If someone has several projects in his repository, he won't be surprised 
he has to say foo.12 or bar.27 to identify a revision; and these are 
about as friendly as you can imagine. Admittedly the term "branch" may 
be misleading here.

> That seems to miss the point I made, that a sprinking of hash bits
> into an alternative naming scheme can make it much simpler to
> implement and to understand.

Hmmm. I don't see how. The big difference is whether you settle for 
"merely" uniquely identifying a revision, or whether you want also to 
describe the "lineage" of the revision. Hashes are perfect for the 
former. Something like foo.1, foo.2, ... is perfect for the latter; I 
don't see how adding some hash bits helps there. Can you give an 
example?

> It's trivial to design and implement hashes that are a lot more
> human-compatible, and certain to succeed.

I don't know about "trivial", but no argument it can be done. It is 
still limited to "random" unique id, though.

> There is no conceivable 
> merit to sticking with hex in any case.  Even octal or pure
> alphabetic (e.g. a-q) would be better -- unless the goal is to keep
> away people who aren't macho enough.

My point was that _if_ there's a good "historical" id system, the need 
for "random" ids is reduced - possibly so much that you use them so 
rarely, the fact they are unfriendly isn't an issue. That's a pretty 
big "if".

> Who knows how well any experimental naming scheme will turn out?
> Should we insist on driving users away until after all the
> experiments are done?  Anyhow, every alternative would benefit from a
> sane hash format, for disambiguation.

Point taken. Like I said, it boils down to whoever actually does the 
coding. That's the beauty of an open-source project :-)

Have fun,

 Oren Ben-Kiki




reply via email to

[Prev in Thread] Current Thread [Next in Thread]