[Monotone-devel] Re: fatal error question

[Jeff Bowman]

Nathaniel Smith <njs <at> uclink.berkeley.edu> writes:

> 
> >===== Original Message From Jeff Bowman <wolfjb <at> bigfoot.com> =====
> >monotone: fatal: std::logic_error: netsync.cc:565: invariant 'I(j !=
> >attach_map.end())' violated
> 
> If you look at the archives some, this is a little bug in 0.15's netsync 
> implementation that is fixed now.  The bug prevents pushing the fix to the 
> usual server, though, until Graydon gets back from his trip to Boston and can 
> upgrade the server...
> 

sorry, I'll try to do better looking in the archives before I post. 

[snip]


> >so, the question is, when errors like this happen, how does one recover. 
> >This 
> is
> >a lot of effort for some of my users to try to figure out. I'm not always
> >available to help walk them through processes like this.
> 
> Simplest is to post a bug report to the mailing list and wait a bit 
> 
> Second simplest is to wait a week or two for the new code in the changesets 
> branch to stabilize a bit; the changesets update was a pretty major change in 
> monotone's guts, and people only started using it to flush the bugs out about 
> a week ago... of course, it will go faster if you help flush them out too 
> 
> >Also, haveing created the second db and syncing with another user (jim in 
> this
> >case) can I delete the original db and rename the second to the original?
> 
> Not entirely sure what the question here is, but yes, in general, monotone 
> databases are just ordinary files that you can rename, copy, delete etc. as 
> you want.  (The only little caveat is that if you have a database foo.db, and 
> there's a stray file called foo.db-journal, then run 'monotone --db=foo.db ls 
> keys' or something before renaming your database; the -journal file is 
> created 
> by sqlite and contains rollback information for after a monotone process was 
> killed or the like.  Losing or deleting this file can cause corruption.  
> Running any monotone command against the database will automatically perform 
> the rollback and delete the journal file.  See 
> http://www.sqlite.org/lockingv3.html section 6.0 for more information.  
> ...This is really not that big a concern most of the time, though; the way 
> monotone is written, it's almost impossible to get it to actually crash -- 
> kill -9 and power outages are the only likely ways to actually get into this 
> state.)
> 

hmmm, let me try again, you probably already answered the question though. My
"work around" to the fatal error I was getting was to create a second db. In
this case I had the original db (beth.db) and the second db (beth2.db). The
question was, can I delete beth.db and rename beth2.db to beth.db and still have
a working monotone system. The answer seems to be yes, as long as I do something
like monotone ls keys to handle the issue with the -journal file before the
delete/rename operation.


[snip]

Thanks so much for your help and advice. We (one of the companies for which I
work) are about to put this into use maintaining our production code. The only
other questions I have are related to listing information. I'm still reading the
man page, but I don't see a way to list all the tags I have created.  It looks
like I can use monotone ls keys to see for whom I have keys, monotone ls
branches to see all the branches I have created, but I don't see monotone ls
tags (?)

Thanks,
Jeff