Re: [Monotone-devel] Re: results of mercurial user survey

[Justin Patrin]

On 4/28/06, Nathaniel Smith <address@hidden> wrote:
> On Thu, Apr 27, 2006 at 09:58:29PM -0400, address@hidden wrote:
> > On Thu, Apr 27, 2006 at 04:26:12PM -0700, Nathaniel Smith wrote:
> > >
> > > As it happens, the actual checking proper seems to be almost invisible
> > > in profiles of 0.26's pulls.  There's still some reason to think that
> > > this is all doable.  So, that's why I think we should keep trying the
> > > "improve speed while refusing to give up safety" strategy for now...
> >
> > If you give up on safety with an archiving tool, what's the point of
> > having one?
>
> Actually, the answer to this is, "to get work done".  It took me a
> while to figure this out :-).  But in fact, in real life, a lot of
> people use a VCS more for day-to-day coordination and distribution,
> and don't care about history much at all.  I've certainly been shocked
> by how cavalier some people are with just tossing out history...

You've hit the nail right on the head, as usual. The operative phrase
is "to get work done". The issue is not that monotone is consistent
and does data integrity checking. This is very useful. The issue is
not that history is being kept, this is also very important. The issue
is really that the newbie is the one left holding the short end of the
stick and paying a large initial cost to try to use something new,
something which they may just decide not to use once they've gotten
it. Doing a pull and waiting for hours while their machine computes
SHA hashes is a very large up-front cost to pay for being able to try
out some new code and a new SCM. And on top of all of this, if a
problem *does* happen it's on this poor newbie's head that the
responsiblity for alerting others to the inconsistency of the data
lies.

> I have some background, even before monotone, in looking at _real_
> archival problems -- e.g., scientific data -- where it really is
> a kind of sacred trust to never lose anything.  So that biases me a
> bit :-).  And, honestly, this is one of those places where we may know
> a better than the users.  Or at least, I can definitely imagine being
> in the throes of getting something done, and throwing out history if
> it lets me get there a little quicker... but then regretting that
> much, much later, when the particular task is long gone but so is the
> history.
>
> So I'm not saying we _shouldn't_ keep an archival frame of mind.
> Just, we should remember that many users _don't_ have such a frame of
> mind -- and we need to be a good tool for them too.  If nothing else,
> that's the only way their data will be safe!  Imagine if some clever
> IT guy had set up the staff at the library of Alexandria to use
> monotone... ;-).
>
> (What, so we have to simultaneously optimize for two incompatible and
> contradictory use cases?  Welcome to VCS design...)

Here's a possible solution which I have just thought up, spur of the
moment. Include a --no-consistency-checks option to stop the hashing
and consistency checks on pull, but keep track of this in the DB.
Allow the user to check out a working copy and work with it, then when
any other event happens (I'm thinking commit, push, or allowing pull
via mtn serve) monotone will do the obligatory consistency check. It
needn't be on every revision in the DB, only the ones which are
connected to the current one by ancestry.

This way you allow for a quick pull and checkout to allow people to
start using whatever project happens to be in monotone.

Yes, this is just a case of deferring the cost and the cost will still
be paid, but at least it's less of an up-front cost and more of a
"You've comitted to this, now you have to make sure that what you have
is consistent". There could (should) even be special messages for
these cases. When --no-consistency-checks is used a message pops up
(no user verification, just a message) that tells the user that this
will defer the checks for later. Then on commit/push/serve another
message is displayed which tells the user that the DB (or revisions
affected) is being consistency checked and that this can be avoided by
not using --no-consistency-checks.

--
Justin Patrin