Re: [Monotone-devel] Re: Few remarks

[Nathaniel Smith]

On Thu, Dec 02, 2004 at 12:52:59PM -0500, graydon hoare wrote:
> >When working locally, such an integer in unique. So, while keeping
> >the hash for obvious reasons, an integer "alias" associated with
> >the hash in order to make things more userfriendly would be nice.
> 
> such integers would not be particularly stable, as your database can 
> acquire revisions "in the past" retroactively when you sync with others.
> 
> one stable numbering scheme which posesses the property you want (N+K is 
> a child of N) would be to number the immediate children of *each* 
> revision by the order they arrive in your database: consider the "first" 
> child of N as N+1, and use a .fork.seq format for the remaining children 
> a la CVS.
> 
>   first child: N+1
>   second child: N.1.1
>   third child: N.2.1
>   ...
> 
> I guess that would probably make the UI a fair bit friendlier; it's been 
> hard to nail down this concept before revisions existed, but now that 
> it's a strict DAG I can see that it'd probably work. you'd chew up a 
> little bit of database space with this, but I'm not opposed to 
> implementing it.

This sounds doable, but I'm dubious that it actually improves
user-friendliness.  On the one hand, you have shorter ids, okay, and
ones that you can do some reasoning about ("1.2 is the child of 1.1"
etc.).  On the other:
  -- it's a new concept -- now we have two different, contradictory
     ids for revisions.  It doesn't help that they're textually
     ambiguous --- is "12" one of these numbers or a SHA1 prefix?
  -- users can never just forget about SHA1's, because any time they
     talk to other people they have to change gears and use SHA1's.
     Talking to other people seems like a pretty important activity
     given that Monotone is a collaboration tool :-) It also creates a
     new place to make mistakes.  How long until we have a bug report
     that we can't reproduce because someone gives us a log that uses
     these types of identifiers, and ours are different?
  -- they don't have _that_ much structure; with CVS, I don't think
     I've _ever_ used version numbers as anything but opaque
     identifiers.  They come entirely from the innards of the VCS
     tool, and have no relation to any other way I think about the
     software.
So I dunno if the trade-off is really worth it here.

That said, the one example I can think of is that I might have
used them occasionally with 'cvs diff'; if I poke around and
determine that some revision is 1.5, I can immediately figure
out that if I want to know what changed in that revision, I use
"-r1.4 -r1.5".

Hmm, I think I can make a general argument, in fact:
  Point the first: people don't care about these sorts of numbers in
    an absolute scale.  If I just tell you something is revision
    8.9.38.1, you have no idea what that means.  People only care
    about relative numbers (that number becomes meaningful if I'm also
    talking about 8.9.38.4 at the same time).
  Point the second: mostly, this still doesn't matter for viewing
    revisions, because the only sane way to examine history in
    Monotone is through some graph viewer anyway.  If I'm trying to
    find the relation between two versions, I'll pull up my
    visualization tool, not try to decipher obscure strings of digits;
    it'll be way more informative, no matter how clever our coding for
    the digits.
  Point the third: this doesn't apply as much for interacting with
    revisions; I may well want to, given a revision, generate the id
    of its parent(s), or of its child(ren), in cases like the diff
    example above.
Point the conclusion: the real problem is to have some way to, given
an id, refer to a related revision.

If that's right, then maybe what we need is some sort of
itty-bitty-mini-language for referring to revisions?  We already have
this with the selector syntax; perhaps it should be extended some?
I'm always leery of inventing a new syntax when something simpler
might do, but there's some independent reason to think this might be a
good idea; we have Too Many Namespaces and have to tame them
_somehow_.  We have revision ids, and file ids, and tags, and dates,
and authors, and branches, and branch heads, and intersections of the
above, and 'the current working copy', and parents/children of the
above, and some file name relative to one of the above...

Here, I'll throw in some extremely disjointed notes I made to myself a
while back trying to explore this space a little bit...

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."

This email may be read aloud.

namespaces.txt
Description: Text document