[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: user-friendly hash formats, redux
From: |
Nathan Myers |
Subject: |
Re: [Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Thu, 9 Dec 2004 07:11:18 -0800 |
User-agent: |
Mutt/1.3.28i |
On Thu, Dec 09, 2004 at 08:57:30AM +0200, Oren Ben-Kiki wrote:
> On Thursday 09 December 2004 06:36, Nathan Myers wrote:
> > It doesn't much matter if some of the words are not OED. You've seen
> > them all, or words very like them, often enough that it won't take
> > any conscious attention to use them even where you can't put your
> > finger on a definition. Thus, "bux", "wix" and "dux" cause no
> > trouble in practice even if you know of no trademarks that use them.
>
> That might be true, for an American :-) The first thing that comes to my
> mind when I hear "sho" is a Japanese word - wasn't it the code name for
> the Japanese operations in Leyte bay? I suppose that proves you can
> always find _something_ you recognize in a short word...
Exactly. However, it *is* easy to come up with pathological cases,
which I have tried hard to avoid, such as synthetic words that sound
the same as real words that are also present.
> > > That said, I'm less convinced that this approach is necessary in
> > > the first place, given that CVS-like cross-db stable revision ids
> > > are achievable (using the branch/fork owner's E-mail address).
> >
> > That makes a lot of assumptions. It assumes there is only one
> > project tree in a repository, or that one must identify in commands
> > which project, i.e. main trunk, is being operated on...
>
> Which "Branch". Yes, you need to specify the branch name; the "full"
> revision id is "<branch>.<version>[.<author>-<fork>.<version>]*". Of
> course, even when a db contains more than one project/branch (a common
> occurrence, actually), you tend to work on one branch at a time, so you
> have a "default" branch in your options or whatever and you don't
> usually need to specify it explicitly.
If somebody has a dozen independent programs in a repository, with
nothing in common between them, they will be confused if you insist
that they are "branches". If you insist that they pick one as their
main project, and either switch back and forth or specify long
designators for the "other" one, they will be very annoyed indeed
-- especially if having had to choose one as the "main" project
affects how names are assigned on the other "branches" when merging
with other repositories.
> At any rate, the point isn't that branch/author/fork ids are intended to
> replace hashes. Rather, they are intended as a complementary mechanism.
> Some usage calls for using hashes, while others are better done with
> branch/author/fork.
That seems to miss the point I made, that a sprinking of hash bits
into an alternative naming scheme can make it much simpler to implement
and to understand.
> Hashes aren't going anywhere. The question is, should effort be spent
> on making them friendlier, or should it be invested in investigating
> automatic history-based revision ids? Personally, I think it is best to
> first experiment with some such scheme - be it branch/author/fork, or
> anything else. If it turns out to work well enough that raw hex hashes
> are no longer an issue, fine. If it doesn't, then implement some
> verbalization method for them. Of course, the real decision will be
> made by whoever actually does the coding. Me, I'm working on the YAML C
> parser...
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.
Who knows how well any experimental naming scheme will turn out?
Should we insist on driving users away until after all the experiments
are done? Anyhow, every alternative would benefit from a sane hash
format, for disambiguation.
Nathan Myers
address@hidden
- [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- [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
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux,
Nathan Myers <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10