[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Few remarks
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Re: Few remarks |
Date: |
Fri, 3 Dec 2004 03:08:41 -0800 |
User-agent: |
Mutt/1.5.6i |
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
- [Monotone-devel] Few remarks, Jérôme Marant, 2004/12/01
- [Monotone-devel] Re: Few remarks, Bruce Stephens, 2004/12/01
- Re: [Monotone-devel] Re: Few remarks, Jérôme Marant, 2004/12/02
- [Monotone-devel] Re: Few remarks, Bruce Stephens, 2004/12/02
- [Monotone-devel] Re: Few remarks, graydon hoare, 2004/12/02
- Re: [Monotone-devel] Re: Few remarks, Derek Scherger, 2004/12/02
- Re: [Monotone-devel] Re: Few remarks,
Nathaniel Smith <=
- Re: [Monotone-devel] Re: Few remarks, Oren Ben-Kiki, 2004/12/03
- Re: [Monotone-devel] Re: user friendly revision identifies (was: Re: few remarks), Emile Snyder, 2004/12/03
- [Monotone-devel] Re: user friendly revision identifies, graydon hoare, 2004/12/03
- [Monotone-devel] Re: user friendly revision identifies, Emile Snyder, 2004/12/03
- Re: [Monotone-devel] Re: Few remarks, Henrik Holmboe, 2004/12/03
- [Monotone-devel] Re: Re: Few remarks, John S. Yates, Jr., 2004/12/03
- [Monotone-devel] Re: Few remarks, Bruce Stephens, 2004/12/03
- [Monotone-devel] Re: Few remarks, graydon hoare, 2004/12/03
- [Monotone-devel] user-friendly hash formats, redux, Nathan Myers, 2004/12/03
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/04