[Monotone-devel] Violated invariants, nasty server keys, ignored hooks

[Oleg Polianski]

Hi there,

 I have been pondering what I could have done wrong contemplating
 on these two use cases.

 1. I had a monotone 0.17 database created earlier on, which I have
    recently migrated on to the 0.18 format. Since that happened,
    I can't perform any file related operations anymore (add and drop
    in particular), `monotone' informs me of a violated invariant:

% monotone --db=../rmsgd.db.backup add README
monotone: fatal: std::logic_error: path_component.cc:53: invariant 
'I(!null_name(*i))' violated

    When I look into the MT/debug file, I can't find anything useful
    that would give me a clue or a hint of direction to look in,
    with the last several lines reporting

db.fetch("SELECT data FROM 'manifests' WHERE id = 
'439ddc4b78e2e8e858f29f2005293833c695440e'")
old manifest has 63 entries
work path is MT/work
checking for un-committed work file MT/work
read rearrangement from MT/work
'README' prefixed to 'README'
path_component.cc:53: invariant 'I(!null_name(*i))' violated

    The problem is persistent all the way down the project tree.
    Any real reason for that?

 2. To work the first problem around, I decided to afford the luxury
    of recreating the monotone database from scratch and do a fresh
    import of my source code on host X. Having done that, I went on
    to host Y, where I created another empty monotone database and
    attempted to do a full sync (X->Y). One of my intentions was for
    all previously generated and used private and public keys to
    stay the same, so after I had recreated each database, I had
    also extracted the keys from a backup copy of each one and then
    reloaded them (via `monotone read') into each database accordingly.
    Now, when I try to sync the Y database with the X database,
    `monotone' on the receiving side, among the lines, spits out

monotone: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
monotone: @ WARNING: SERVER IDENTIFICATION HAS CHANGED              @
monotone: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
monotone: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY
monotone: it is also possible that the server key has just been changed
monotone: remote host sent key 88de5cc64a05fe7f3d17522e675cef860cce2ef7
monotone: I expected 549c2e9f3556ee5ba39f6bc00e8aa25d0f15a8c5

    The thing is that I don't have such a server key or anything
    that closely resembles the 549c2e9f3556ee5ba39f6bc00e8aa25d0f15a8c5
    fingerprint neither on the serving side nor on the sending
    side. This has left confused even more.

 There is actually a third slight problem, which stems from the
 collection of several different things, I guess, mostly related to
 fiddling with the private and public keys via the means of
 `monotone pubkey/privkey' and the subsequent `monotone read' and
 expresses itself as ignoring the `get_passphrase' hook in my
 `~/.monotonerc' file that worked before just beatifully.

 I still have a glimmer of hope that I would not have to go through
 all of this each time I upgrade the monotone binary and I would
 appreciate any help in dealing with these peculiarities of the
 monotone's behaviour. Additional information can be easily
 provided, should that be required.

Thanks,
Oleg