Re: [Monotone-devel] Push can pretend it is successful while it is not

[Nathaniel Smith]

On Tue, Aug 16, 2005 at 11:00:56AM +0200, Marcel van der Boom wrote:
>   monotone: read from fd 1924 (peer mt.xaraya.com:15000) closed OK  
> after goodbye
> 
> So, this looks like it ran successfull, right?

Hmm.  It looks like what happened is that it _did_ run successfully
(in the sense that it successfully transmitted all information), but
then before the server finished committing the transaction to disk it
ran into a little problem:

> 2. Looking on the server in the log file, this push corresponed with:
[...]
> monotone: error: sqlite error [5]: database is locked

Apparently someone else ran monotone against the server database while
the server was running?  "Don't do that then..."  This is an annoying
and long-standing bug, that we tend to detect this error later rather
than sooner.  It's a limitation in sqlite, that no-one has gotten
around to taking up with them upstream -- we use sqlite as a simple
data store, not a full-on database with concurrent access and all
that; we would really like to have a way to just say "give me a read
lock" or "give me a write lock", so concurrent access can be detected
early.  But, while sqlite does have such locking internally, it
doesn't expose it.  (Ideally such locks would also cause a fault if
you attempted to write while you had only a read lock, i.e. you would
have to be explicit about what you wanted.)

The other bug is that apparently netsync can finish successfully
before all data is written to disk.  We knew this, actually... hmm.
The netsync "goodbye" phase is just a way of determining that
everything that was supposed to go over the wire has, in fact, gone
over the wire, so there's no way in there ATM to even confirm disk
writes.  Could you file a bug about this on Savannah?

> 3. monotone db check came up with all sorts of reference errors missing

Could you give more details?  Because...

> The self repairing feature is of course very nice ;-) but what would  
> have happened if people would have pulled the database in the mean  
> time? It looks like the 'metadata' of the revision(s) was registered  
> in the database, but the actual changes were not applied. What  
> happened here?

...if this is true there's another bug; but it doesn't sound like it
was quite true, from your mention that viewmtn didn't show the
revision.  What _should_ have happened is that the files and perhaps
manifests were stored to the db, but the revision (the "metadata") was
not; monotone stores things in this order on purpose, so that you
might have some unreferenced (and thus pointless) data sitting around
your db, but you'll never have any references to data that just isn't
there...

> PS
> Can I request you guys install a proper bugtracker? The one at  
> savannah doesnt really do the job imho.  Bugzilla seems fitting for a  
> project like monotone.

Eh, yeah, the savannah one rather sucks.  Unfortunately, all the
bugtrackers I've spent much time with have rather sucked too, so I
have trouble getting really excited about upgrading my suck (though
I'm pretty sure we can do better than Bugzilla).  IOW, if someone
makes something better, I'll use it, but I'm not going to figure out
how to administer such a thing myself this week...

I _would_ love to have something that made it easier to manage "todo"
type lists, and was ergonomic to deal with (i.e., "it shouldn't take 5
minutes of clicking around to enter a bug") -- that could replace
things like http://venge.net/monotone/quickies.html ...

-- Nathaniel

-- 
When the flush of a new-born sun fell first on Eden's green and gold,
Our father Adam sat under the Tree and scratched with a stick in the mould;
And the first rude sketch that the world had seen was joy to his mighty heart,
Till the Devil whispered behind the leaves, "It's pretty, but is it Art?"
  -- The Conundrum of the Workshops, Rudyard Kipling