[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Time for a release

From: Richard Levitte
Subject: Re: [Monotone-devel] Time for a release
Date: Fri, 04 Apr 2008 20:18:19 +0200 (CEST)

In message <address@hidden> on Fri, 4 Apr 2008 13:24:30 -0400, Jack Lloyd 
<address@hidden> 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> 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 "" "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 address@hidden
  mtn: connecting to
  mtn: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  mtn: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  mtn: it is also possible that the server key has just been changed
  mtn: remote host sent key 3e6f5225bc2fffacbc20c9de37ff2dae1e20892e
  mtn: I expected 
  mtn: 'mtn unset known-servers' 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

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


Please consider sponsoring my work on free software.
See for details.

Richard Levitte                         address@hidden

"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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]