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

[Nathan Myers]

On Thu, Dec 09, 2004 at 08:57:30AM +0200, Oren Ben-Kiki wrote:
> On Thursday 09 December 2004 06:36, Nathan Myers wrote:
> > It doesn't much matter if some of the words are not OED.  You've seen
> > them all, or words very like them, often enough that it won't take
> > any conscious attention to use them even where you can't put your
> > finger on a definition.  Thus, "bux", "wix" and "dux" cause no
> > trouble in practice even if you know of no trademarks that use them.
> 
> That might be true, for an American :-) The first thing that comes to my 
> mind when I hear "sho" is a Japanese word - wasn't it the code name for 
> the Japanese operations in Leyte bay? I suppose that proves you can 
> always find _something_ you recognize in a short word...

Exactly.  However, it *is* easy to come up with pathological cases,
which I have tried hard to avoid, such as synthetic words that sound 
the same as real words that are also present.

> > > That said, I'm less convinced that this approach is necessary in
> > > the first place, given that CVS-like cross-db stable revision ids
> > > are achievable (using the branch/fork owner's E-mail address).
> >
> > That makes a lot of assumptions.  It assumes there is only one
> > project tree in a repository, or that one must identify in commands
> > which project, i.e. main trunk, is being operated on...
> 
> Which "Branch".  Yes, you need to specify the branch name; the "full" 
> revision id is "<branch>.<version>[.<author>-<fork>.<version>]*". Of 
> course, even when a db contains more than one project/branch (a common 
> occurrence, actually), you tend to work on one branch at a time, so you 
> have a "default" branch in your options or whatever and you don't 
> usually need to specify it explicitly.

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 you insist that they pick one as their 
main project, and either switch back and forth or specify long 
designators for the "other" one, they will be very annoyed indeed
-- especially if having had to choose one as the "main" project
affects how names are assigned on the other "branches" when merging 
with other repositories.

> At any rate, the point isn't that branch/author/fork ids are intended to 
> replace hashes. Rather, they are intended as a complementary mechanism. 
> Some usage calls for using hashes, while others are better done with 
> branch/author/fork.

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.

> Hashes aren't going anywhere. The question is, should effort be spent
> on making them friendlier, or should it be invested in investigating 
> automatic history-based revision ids? Personally, I think it is best to 
> first experiment with some such scheme - be it branch/author/fork, or 
> anything else. If it turns out to work well enough that raw hex hashes 
> are no longer an issue, fine. If it doesn't, then implement some 
> verbalization method for them. Of course, the real decision will be 
> made by whoever actually does the coding. Me, I'm working on the YAML C 
> parser...

It's trivial to design and implement hashes that are a lot more 
human-compatible, and certain to succeed.  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.

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.

Nathan Myers
address@hidden