[Cabal] beta6 and after

Ethan Blanton elb at psg.com
Sun Dec 10 17:11:05 EST 2006

At the risk of replying to myself one too many times ... ;-)

Ethan Blanton spake unto us the following wisdom:
> I believe I have a working migration script (really, pile of scripts,
> Makefile, and black magic), and I've started a migration.  If all goes
> well, in a day or two we'll have a complete monotone history of the
> single, linear Gaim tree from revision 9 in svn through whatever the
> current revision is at the time it gets there.  I'm not to the "have a
> working subversion install" stage yet, so there's still a possibility
> it'll fail, but I'm pretty sure I'll be able to make it go sooner or
> later.

The conversion seems to have gone off without a hitch.  (Well, if you
can call that process "without a hitch" in any way.)

Unfortunately, this means that we're going to have a little bit of a
flag day coming up.  Fortunately, monotone will help us with this.

Due to the way monotone revisions work (with revision IDs being
dependent on the parent revision IDs), the revision ID for the first
logical revision which exists in both the "old" monotone history
and the "new" monotone history, r16024, is different in each history.
This means that you won't be able to simply update to the new line of
history, you'll have to throw your old databases out and check out
fresh.  Fortunately, no one has been editing against the old history
-- or if you were, you were doing it against my instructions.  ;-)
What I'm going to do is create a non-zero "epoch" for the new history.
This will prevent revisions from the old history from tainting
anything in the new history -- which wouldn't be the end of the world,
it would just mean we had junk revisions floating around, but since we
can avoid it, I will.

You don't have to know anything about this epoch.  However, if you try
to sync an old database against the new database once it hits the
netsync server, you'll get an error (like the one below) telling you
that the epoch has changed and the sync will fail.

  mtn: warning: protocol error while processing peer localhost:
  'received network error: Mismatched epoch on branch im.pidgin.gaim.
  Server has '0000000000000000000000000000000000000000', client has
  mtn: error: processing failure while talking to peer localhost,

As soon as I get word from datallah that trac won't puke when I change
over the netsync server, I'm going to do so.  (Daniel, as you probably
gathered from the above, you'll have to pull the new history fresh for
trac once this is done.  I assume you want to shut off syncing, I'll
change over the server, you'll pull a fresh database and turn syncing
back on.  However, I don't know what's best for you, so I'll wait for
your word that it's cool to change.)  Hopefully this won't be too much
pain for anybody.

With this, I'm confident we can go ahead with a switch to monotone.
There is still some work to be done (such as inserting tags in the
history, connecting critical historical branches (like 'oldstatus'),
etc.), but none of it should be impossible or anywhere near as hard as
conversion from svn was.  If anyone thinks we should *not* switch,
let's start that discussion now.

For the record, the new history is about 135MB.  Anyone pulling
pidgin history for the first time (until monotone gets partial pulls,
which should be in the near-ish future, I hope) will have to pull and
checksum this much data, which takes some time.  I'll have timing
figures as soon as I can get the server up and running.


The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://pidgin.im/cgi-bin/mailman/private/cabal/attachments/20061210/ef6d22ca/attachment.pgp 

More information about the Cabal mailing list