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

[Phil de Joux]

On Thu, 09 Dec 2004 16:42:24 -0500, graydon hoare <address@hidden>  
wrote:

> Nathan Myers wrote:
>
> > 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.
>
> well, I said earlier that I've "been resisting" this, and I meant it. we
> talked about it, njs implemented a little prototype demonstrating it,
> and I decided I really didn't like it. I really do resist the idea that
> a non-numeric quasi-random number is any friendlier than a numeric one.
> it's more rememberable, yes. but it's also *weirder*.

I see this thread and think monotone should be split up into parts.

The monotone source control system is cert based. There are branch certs,  
ancestor certs and informative meta-data certs. Versions here are  
specified by entire 40 character hex SHA1 codes. Monotone itself should  
stop here.

In the pdf help file for monotone, in 'Special Topics|Selectors' there are  
different kinds of 'human friendly' version selectors, abbreviated hex  
SHA1 codes, username/periods etc. I think that this functionality should  
*not* be in monotone. This is a higher level user interface service. If  
people want to use a source control system with incremental version  
numbers (monotonically incrementing ones at that :-)) then that can be  
layered on top of montone using informative meta-data certs.

Please split monotone into the core product, ie. call it a library or API  
whatever, and one or more end user interface applications that use the  
core product under the hood, eg. a command line tool, a GUI tool for gtk,  
a winforms GUI tool etc.

-Phil