[Monotone-devel] Sanity checking (Was: Re: [ANNOUNCE] monotone 0.18)

[Jon Bright]

Olivier Andrieu wrote:
> Now, maybe someone should point out on LKML or on the git ML how
> similar in architecture git and monotone are. I mean, if some people
> like the idea of addressing things by SHA1 hashes, the ancestry graph,
> etc. they might as well hack on monotone :)

I hate to say it, but I fear it's a dead argument while monotone's speed 
issues remain.  0.18's a big improvement, but it's still not exactly 
spritely, especially on a tree the size of the kernel - and most of the 
time is going on the sanity checking.

I'm sure Nathaniel won't like the suggestion, but could we maybe 
consider a 
--no-sanity-checking-yes-i-realise-this-might-screw-up-my-life-and-eat-helpless-orphans 
option?  Relying on most people not using this and finding/reporting any 
problems in the codebase, while people who do use it are left to wail 
unheard in the darkness if they hit problems?

I understand the case for the sanity checking, but I don't think there's 
much prospect of optimising it to be an order of magnitude (or two) 
faster.  Since the justification for the checking at the very basic 
level is "corrupting stuff drives away users", I figure we need to 
reexamine the situation if the speed hit from the sanity checking starts 
frightening off users...

If a no-sanity-checking option isn't viable (or is too hated), maybe we 
could at least look at a seriously-reduced sanity checking option?  Do 
we really need to go three revs back?

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com