Re: [Monotone-devel] beginner questions

[Jeremy Fitzhardinge]

On Thu, 2004-05-27 at 15:36, Nathaniel Smith wrote:
> On Sat, May 22, 2004 at 07:27:22PM +0100, Zbigniew Zag?rski wrote:
> > hi all
> > 
> > I've installed monotone yesterday ... now I'm after reading 
> > documentation, and i have some questions before i start using it more 
> > widely than testing:
> > 
> > 1. why monotone use those ugly SHA1 signatures in *user interface* instead
> >    well known revision numbers ... it's really weird ... how can i use 
> > typical
> >    revision numbers instead of tagging everything ? I'm asking about user
> >    interface, i untersand reasons to use SHA as internal file/rev 
> > identifiers.
> 
> Because of the "distributed" part of being a "distributed version
> control system".  Say we're using CVSy revision numbers, and we both
> check out version 1.1, and make some changes, and commit to our
> separate databases.  There's no way for either of us to know about the
> other, so presumably we both end up versions named "1.2", except the
> actual data in them is different.  This is already confusing. 

This is true, but Zbigniew's question is a good one - the SHA1 hashes
are a big pain to use, and will be forever turning people off.  I know
why they're there and what they're for, but I don't like to use them,
even in abbreviated form.  The fact that they convey no information
about the files and versions to me, the user, makes them very hard to
work with - I can't easily remember that df2834* is the version before
9283d* and after 1238b* without noting it to myself explicitly, whereas
it's implicit in 1.2, 1.3 and 1.1.  When I'm doing merges and so on, I
have usually enough mental state to keep track of without this added
complication.

They are, of course, fundamental to Monotone's operation, but couldn't
Monotone generate simple version numbers for local use?  They'll shift a
bit in time as you sync with other people, but you can use them as you
do a series operations in which you need to keep things in mind?  A walk
over the DAG should generate a set of reasonably sane-looking numbers
which won't change too much as the DAG evolves.

I think BitKeeper works in this way.  There are underlying
globally-unique file versions which it uses internally to keep track of
things, but it expresses versions to the user with more conventional X.Y
version numbers.  When you sync with someone else they can change, but
they still quite usable.  (The disadvantage of this is that BK keeps the
"real" version numbers so hidden that people use the transient version
numbers when talking to each other, and BK uses them as part of the web
interface, which means that a URL referring to a particular version will
refer to different actual changes over time.)

        J