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

[graydon hoare]

Oren Ben-Kiki wrote:
> On Sunday 05 December 2004 21:39, graydon hoare wrote:
>
> >   - another local sequential system might involve keeping a sequence
> >     number for each author, sorted by date, such that the numbers go
> >
> >       "derek-10", "graydon-12", "matt-72", "joel-13", "derek-11"
>
>
> Neat, but I don't see it solves the core problem though. First, I still 
> don't know what the revision before gordon-206 is. Is it gordon-205 or 
> matt-71?

it doesn't solve "the" core problem because there's no single problem 
we're trying to solve. it solves part of some problems: each revision 
has a probably-unique-to-your-local-database name which you might not 
find odiously difficult to copy from a log to a command line. but you're 
right that it doesn't make immediately-sequential numbers denote 
immediately-sequential revisions.

> (An aside: I never could stand CVS branch naming. I always wondered why 
> they don't use letters for branch ids: I find 3a.12 to be "clearly" 
> revision 12 of branch 'a' of revision 3. In contrast I need to work on 
> parsing 3.1.12. And compare the readability of 3d.4b.11 and 
> 3.4.4.2.11... is it just me?).

yes, I did find CVS' rev.branch.rev.branch... a little surprising at 
first, but I know it now, and it has the advantage of familiarity to 
some. your idea also sounds pretty good, although the english alphabet 
is slightly more locale-specific than arabic numerals.

> A problem with x.y.z (if I understand it correctly): My db has 1 --> 2 
> --> 3. Yours has 1 --> 2 --> 3'. We sync. Now, in my db, 3' is 2.1.1, 
> while in yours, 3 is 2.1.1. If we communicate to each other, we can't 
> use the numbers "3" and "2.1.1" reliably.

oh, I'm sorry, I wasn't sufficiently clear: the idea of an x.y.z number 
or a author-NN number is purely for *local* use. you can't communicate 
them usefully to other users.

I'm lead to believe that bitkeeper uses local x.y.z sequence numbers -- 
I have only ever seen it running on a friend's machine so I don't really 
know -- and afaik they don't cause too much strife. but maybe I'm 
misinformed, or misunderstood.

> There seems to be an inherent trade-off. What is more important:
>
> - Stable local ids, or
>
> - Consistent ids across dbs after a sync?

yes, this is definitely a core tradeoff in the discussion. the former is 
useful when talking to your local database -- which is most of the time 
-- but the latter is useful when chatting in IRC or email, or making 
notes in a bug tracking system. I was assuming that we'd carry on 
telling people that hashes were the "global" ID to use, when discussing 
revisions outside your own database. but maybe that assumption is not so 
good?

> You can avoid it, with a price: have a strong notion of a branch's "main 
> line" (or "trunk").
>
> If I understand correctly, Monotone today doesn't have this notion; all 
> heads are equal, and you need to merge before you have a "latest 
> revision". But suppose that a certain path of revisions was "blessed" 
> somehow (the "main line"). It would always be numbered 1 - 2 - 3... 
> You'd need something like the branch's key to mark a revision as "main 
> line".

it's interesting you mention this. your hunch sounds correct; I think it 
would help with the number-assigning problem. but it's coincidentally 
something which a number of people have asked for: the idea that one 
head is "more trunky" than the others, even if only at a UI level. even 
if, say, all heads are all represented as equals under the covers, 
there's a human-political element which I've been told is desirable, 
that any line of development have a discriminated leader or center.

while I'm not completely sold on the notion yet, another reason this 
might be a good idea to introduce is that it makes interoperation with 
"single headed" VC systems easier. for example, it would be a very 
helpful abstraction to use if we ever wanted to make bidirectional 
gateways to CVS or arch repositories. these systems inherently have only 
one head: working copies are transient anonymous micro-branches, and you 
have to pick a separate name to form any greater form of branch. it 
might be nice if monotone knew how to think about trunks, even 
superficially.

I'm honestly at a bit of a loss on how to implement that, though. the 
only thing which I can imagine is a 3rd party serializer -- some online 
number-dispenser -- which sounds sort of like a central point of 
failure. perhaps that's ok; it would be a very "soft" form of failure, 
since it would only affect the names you call things by, not the things 
you can do with those names.

> You have created a small query language for revision ids. Being able to 
> pick a revision based on a general query is a good thing. Creating a 
> private query language has a lot of disadvantages, though. Perhaps you 
> should allow the use of an SQL query instead?

yeah, I was considering that. it'd require a slightly larger set of sql 
functions, but it's not beyond reason.

-graydon