In message <[EMAIL PROTECTED]> on Fri, 4 Apr 2008 13:24:30 -0400, Jack Lloyd <[EMAIL PROTECTED]> said:
lloyd> On Thu, Apr 03, 2008 at 07:07:20PM +0200, Richard Levitte wrote: lloyd> > It's been a little more than a month, and two other branches have been lloyd> > merged in (among others causing a need to migrate the database), so I lloyd> > think it's time for 0.40. lloyd> lloyd> Random curiosity: UPGRADE says that each known-server var has lloyd> to be unset after moving to (what-will-be) 0.40: why is this? I lloyd> am not seeing anything obvious in the n.v.m log It's an effect of the following NEWS items: - The database scheme has been changed to store binary encoded hashes, instead of a longer hex encoded representation. That reduces the database size and speeds up operations a little. Users who like to fiddle with the database directly are adviced to use the sqlite function hex(), the built-in quote() function as well as the hexadecimal notation x'DEADBEEF'. - Monotone now uses that same binary hash representation internally as well, saving some conversion steps from and to hex encoded notation. The "known-servers" entried looked like this before migrating (extracted with 'automate get_db_variables'): domain "known-servers" entry "guardian.lp.se" "3e6f5225bc2fffacbc20c9de37ff2dae1e20892e" The thing is that migration does nothing with database variables, simply because from a general point of view, monotone doesn't have ANY knowledge about the format of the values. The internal problem is now that the new monotone will have two blobs that it treats as binary, one being the 20 byte binary hash that came from the server, the other (literally) being the 40 bytes composed with the string that came from the variable above. The result, when trying to talk with said server, is this: : ; LANG=C mtn -d DATABASE push [EMAIL PROTECTED] mtn: connecting to guardian.lp.se mtn: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ mtn: @ WARNING: SERVER IDENTIFICATION HAS CHANGED @ mtn: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ mtn: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY mtn: it is also possible that the server key has just been changed mtn: remote host sent key 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e mtn: I expected 33653666353232356263326666666163626332306339646533376666326461653165323038393265 mtn: 'mtn unset known-servers guardian.lp.se' overrides this check DEBUG[MN]: ----- start MN_note_netsync_end mtn: warning: /home/levitte/.monotone/monotonerc:69: bad argument #1 to 'pairs' (table expected, got nil) mtn: error: server key changed Note the really long hash that monotone says it expected. That's the hexadecimal representation of the bytes '3', 'e', '6', 'f' and so on: : ; echo -n 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e | od -t x1 0000000 33 65 36 66 35 32 32 35 62 63 32 66 66 66 61 63 0000020 62 63 32 30 63 39 64 65 33 37 66 66 32 64 61 65 0000040 31 65 32 30 38 39 32 65 0000050 Now, if I remove the above database variable and do a push again, the push will tell me that it got a new server cert with the hash 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e and will now store that hash in its internal representation: domain "known-servers" entry "guardian.lp.se" ">oR%�/��� ���7�-� ." Of course, this could be resolved some other way. We could do this by having the migration code change all database variables in the domain "known-servers", or we could change the recommendation in UPGRADE to an SQL line that makes that change. Either is fine by me. Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel