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

[Oren Ben-Kiki]

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...

> > 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.

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.

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...

Have fun,

 Oren Ben-Kiki