RE: [Monotone-devel] fatal error question

[Nathaniel Smith]

>===== Original Message From Jeff Bowman <address@hidden> =====
>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...

In the mean time, there's a x86 linux binary at:
  http://www.fresco.org/~njs/monotone.bz2
and a source snapshot at:
  http://www.fresco.org/~njs/monotone-snapshot.tar.gz
and in theory the source is available at Joel Rosdahl's server, though I'm 
getting connection refused right now:
  http://lists.gnu.org/archive/html/monotone-devel/2004-11/msg00024.html

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

The only other thing to watch out for is that after a netsync 'sync' that 
covers everything in the database, the two databases should be identical, 
_except_ that private keys are not transferred by netsync; currently the only 
way to get private keys out of a database is to use 'monotone privkey' to 
generate an ascii packet, and the only way to get private keys into a database 
is by feeding that packet into 'monotone read'.

-- Nathaniel