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

[Marcel van der Boom]

On 16 aug 2005, at 15:01, Nathaniel Smith wrote:

> 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:

Yes, should the "transaction" not be rolled back then?

> > 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 is indeed what i thought too, but i'm almost sure this wasn't the  
case. I'm pretty much the only interactive user on this server and  
while i can be absent minded, i'm pretty sure no other mt was  
accessing the db, but i'm not 100% sure. Having said that, i cannot  
think of another situation which would cause this.

> It's a limitation in sqlite,
Yeah, it amazed me in the beginning that that was the case (i'm using  
sqlite for lots of other stuff too), but learned to live with it i  
suppose.


> 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?

http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=14157


> > 3. monotone db check came up with all sorts of reference errors  
> > missing
>
> Could you give more details?  Because...
In the process i did not save the initial output of db check, so here  
it goes from memory, sorry bout that.

There were 200+ errors saying that a file was missing (the revision  
going in happened to change/remove a lot of files) and a couple of  
errors mentioning unreferenced stuff.
The unreferenced stuff is annoying but doesnt worry me, the missing  
files errors let me to think that 'metadata' was stored but actual  
changes were not.

> ...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.
it wouldnt show it in either case, would it?

> 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...
Right, the error messages made me believe the reverse had happened  
(which *would* worry me)
 There is probably no reliable way for me to reproduce this at this  
point though.


> 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 ...

I think the need for people like myself is to have a way to file a  
bugreport / patch and be able to track that easily and being  
reasonably sure a bugreport is useful to the "ones in the know" All  
bugtrackers i've worked with sucked, but it's also a matter of  
getting used to and discipline.

--
Marcel van der Boom
HS-Development BV               --   http://www.hsdev.com
So! webapplicatie framework  --   http://make-it-so.info

smime.p7s
Description: S/MIME cryptographic signature