[Cabal] Tailor badness

Ethan Blanton elb at psg.com
Sat Dec 16 10:48:34 EST 2006

Ethan Blanton spake unto us the following wisdom:
> This may be an artifact of the way the move was done, or it may be a
> tailor bug, or it may be an svn limitation; in any event, I'm going to
> try to find out and fix it.

It's a little of the first and a little of the third.  A (pretty
severe) svn limitation caused artifacts in the tree rearrangment which
created core/ (libgaim/) and gtk/.

Basically, svn does not allow you to move a directory and, in the same
revision, move a subdirectory of that directory out of the moved
directory.  (Hopefully that makes sense.)  This stems from the fact
that svn doesn't really know anything about tree structure; it tracks
all of its files in the directory they live within (the .svn dir).
Moves between directories seem to be some sort of hack, and it must be
fragile.  Due to this, what was accomplished in one monotone commmit
had to be spread over six (!) svn commits.  This probably could have
been done in a way which imported cleanly (I don't know), but for some
reason the migration script left some files in two locations at the
same time -- this causes the svn move to be represented not as a move,
but as an add in a new location.  (As I'm sure we've discussed before,
svn can't actually move -- it can only copy-and-delete.  This leads to
all sorts of weirdness.  You should see the log entries for these
revisions, they're nearly incomprehensible.)  Some revisions later,
the old files were dropped -- meaning that monotone history for the
*new* files was abruptly lost at the point of the copy.

I hand-crafted a monotone revision that covers 16854:16861, to get
around this.  It wasn't too difficult, it just took some time.  All
revisions from 16861 forward were then re-imported with tailor.  All
revisions *prior* to, and including,  16854 are exactly the same as

Again, to avoid cluttering the server database with useless revisions,
I have updated the im.pidgin.gaim epoch.  This means that your extant
local databases against im.pidgin.gaim will no longer sync with the
server.  Please update them accordingly.

As a note, I would like to mention that work which had been done
against these trees before epoch changes would *not* have been lost,
and could be ported forward with a minimal amount of effort.  The
revisions after the change points have had different revision numbers,
but been the same in *form*, as the previous trees; due to this,
changes could be rather efficiently 'mtn pluck'ed from the old, broken
tree to the new, fixed tree without any need for manual merges, etc.
That said, we really do want to get all of these transition pains out
of the way before people start real work on these trees.  *Please*
check Gaim out of monotone and poke at it, and let me know of any
vagaries you may find.  I think I've caught the worst of them (with
Gary's help, in this case), but I'm only one man and there are more
than 15,000 revisions.  ;-)

Note that 'mtn log' on an individual file and 'mtn annotate' are both
very slow; the monotone folks are aware of this, and some
optimizations are in the works.  If you use these to analyze the tree,
just go get a cup of coffee or something.  ;-)  (This said, they don't
have to access the network at all, and once the optimizations are in
place they should be more efficient than their svn equivalents due to

Ceding another day of my life to this transition,

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/20061216/79bfda91/attachment.pgp 

More information about the Cabal mailing list