[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: user-friendly hash formats, redux
From: |
graydon hoare |
Subject: |
[Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Sun, 05 Dec 2004 14:39:25 -0500 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040913) |
Bruce Stephens wrote:
Nathan Myers <address@hidden> writes:
Aliases are good too. To invent good aliases automatically would be
nice. Short, sayable and rememberable (if not "memorable") hash
formats, though, are certainly easier to implement. Once people
stop being spooked by the tutorial, we'll have a better chance of
finding somebody to implement lots of nice features.
It doesn't sound like Graydon wants to introduce features simply to
avoid frightening potential users.
no, that's not true. I'm quite willing to change monotone to avoid
frightening off users. software is really all about human factors, at
some level or another; computers would be happy to sit there idling and
accepting no input from us.
what I'm unwilling to do is make deep changes without giving a fair bit
of thought to what we're trying to accomplish. so I'm glad we're
discussing. I don't enjoy someone throwing down the gauntlet and
deciding there is One True Way of doing things. there are usually many ways.
I see there as being 3 issues to decide:
1. whether hashes-as-identifiers are acceptable, from a human factors
perspective, as an *implementation* technique alone. eg. is it
acceptable for debug logs and whatnot to contain hashes, and for
some parts of the manual to describe hashes in passing, if they are
sufficiently rare in user input and output?
2. whether the UI accepts something which is more user-friendly to
input.
3. whether the UI always (or mostly) prints out the more user-frendly
things when describing revisions, files, etc.
so far I believe #1 is still ok. I think it's ok to use hashes under the
covers. I think for someone who cares enough to *look* under the covers,
they're comfortable enough with the issues to find hashes inoffensive,
even desirable (I've outlined why I feel so). if that's wrong, we have
more work to do. but I think it's ok. if you want to discuss this one
further it's important to say so now, because it's a much deeper amount
of surgery to change.
I think #3 should probably be enhanced if we decide anything for #2: we
should make the log format, the ancestry graph, the status command, etc.
print out whatever format is friendlier for accepting. this would mean
that the status command isn't the *exact* contents of a changeset as
stored within a revision, in the repository. that was a nice
coincidence, but if it can't be maintained I can live with it.
for #2, I already made the UI accept something more user-friendly than
hashes, but it's apparantly not enough. the fact that people are still
bothered by it is evidence that it's not enough. I accept that. it's a
data point, you can't really argue with data. I keep having people say it.
interpreting it is tricky. it might be not enough for a few reasons:
- perhaps entering "2004-08-01T13:44:57" is too cumbersome a way to
enter dates (or not very memorable). but I think that's not the only
point: people's date-memory is fuzzy; it's very rare to actually
refer to a *specific* CVS version by date, just a ballpark. if I
say "I was doing something last friday at 8:51 pm", you might
be able to stash that as little more than "er .. late last week"
in your mind, which makes the event ambiguous with everything
else around that time.
- perhaps bibblebabble or nathan's dictionary approach would help.
I've resisted this because I don't feel like it adds much
*meaning* to identifiers; I think people would in fact find it
easier to look at monotone as some crazy moon-man system if it
insisted on calling your versions "dog-wall-stink-egg" or
"fwee-bazoo-frump-gorf". at least 0x9f798f98ea is somewhat clearly
a number, albeit an unfriendly one.
- perhaps authors and dates, or "the things we already have around
as certs", are less desirable than "sequence numbers". VC has a long
history of using sequence numbers. I posted a couple days ago a
proposal -- quite honestly -- for assigning CVS-style "local" x.y.z
sequence numbers, which is relatively easy to do now that we have a
fixed DAG-shaped revision graph. I'm perfectly willing to implement
that, if it would help.
- 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"
(this would have an interesting social effect of automatically
"ranking" contributors by commit volume, such that I would be
committing "graydon-206", just after "njs-38". also the numbers
would be quasi-stable and quasi-global for teams which shared
complete history.)
I'm willing to completely toss out the selector stuff we have now if
nobody's using it. it's an experiment. I can accept failed experiments,
and we know the command-line is in need of an overhaul anyways. here is
a concrete proposal: what would happen if the command line accepted
revisions in any of 3 forms:
--hash or -h <id> global hash identifier
--seq or -s <author>-<seq> local sequence numbers
--rev or -r <x>.<y>.<z>... local revision numbers
and we ask a hook for your preferences as far as which to print out
(possibly all three) when listing logs, status, etc.
-graydon
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/04
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Derek Scherger, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/04
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/04
- [Monotone-devel] Re: user-friendly hash formats, redux,
graydon hoare <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Christof Petig, 2004/12/06
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Derek Scherger, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, John S. Yates, Jr., 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Tim Woodall, 2004/12/06
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/06
- [Monotone-devel] unique repository ids, Nathan Myers, 2004/12/06