Re: [Monotone-devel] beginner questions

[Adam Logghe]

Jon Bright wrote:
> Adam Logghe wrote:
>
>> While sha-1 hashes may look a bit intimidating, in actually using them
>> in their short form I don't mind them a bit. I would see the addition of
>> "fake" version numbers to be a nuisance and likely to me much more
>> confusing when it counted (when you are trying to work out conflicts in
>> tree states).
>
>
> I'm not sure it would be an improvement, but "real" version numbers
> could also be generated.  You'd graydon.1.1, graydon.1.2, graydon.1.3,
> adam.1.1, and joel.1.1.  These could remain consistent and be unique -

I sign with the same key from multiple machines, which would
break/seriously complicate this scheme. I love the fact that monotone is
portable and flexible even within a single user's workflow. I personally
have 3 machines I check code into locally (I'm going to expand this to
6), and they are(will be) at 4 discontiguous locations (proxy servers at 2).

Monotone is the only version control system I know of that its this easy
to add and remove disconnnected machines that are using the system.

> but I'm not at all sure that this helps understandability or eases the
> average user experience.

It also still comes back to a version <> real version number where none
existed before.

As far as usability in general- to me 1.2.3 is no friendlier than 8cf.

If it's merely because it would look more cvs or arch-like, that does
nothing for me. If there is a bit of cognitive dissonance in learning
Monotone that's probably positive in this instance. People asking about
the sha-1, I hope, elicits some clarity about the strengths of Monotone.

> If it were up to me, I'd leave the version numbers thing alone for the
> moment - even if a real or fake system of version numbering were
> implemented in the future, it's clear that the backend would be sticking
> with SHA hashes.  As such, it has no infrastructure implications and
> isn't something that needs changing as soon as possible.  This being the
> case, I think there's a strong argument for not changing it now, waiting
> until Monotone's matured a bit and then seeing what the user experience
> is for certain common operations and whether that experience could be
> improved via the use of an extra layer of version numbers, or anything
> else.  Any other approach is probably premature optimisation.
>

One change that could be looked at now would be to empasize/pregenerate
some possible unique selectors in addition to the hashes. This would add
more printing to some of the command output but if it can be done
carefully it would be nice.

In other words dont just say "832acblah...." in various command output
but add in adam/yesterday and jon/last week as a unique selector that
could seen and then used, and perhaps reorder the output for
friendliness. There is complexity in generating it though....

One concrete example of tuning instead of throwing out hashes is when
you do "monotone heads" perhaps the sha-1 should be listed second after
the key and date?

Under the cool concepts dept- Ori Berger mentioned "friendly" hash names
in his email.

http://lists.gnu.org/archive/html/monotone-devel/2003-09/msg00063.html

Its called mnemonic encoder-

http://tothink.com/mnemonic/



Adam