It has not been updated for a long time, but today a fix appeared. It seem to be kernel.org-specific though, so don't worry.

Today evening gitte collected a summary of his tailor problems, which I would call a nice collection.

He says:

01:31 < gitte> vmiklos: tailor was limited in many ways.
01:31 < gitte> vmiklos: one, basically branch per branch.
01:32 < gitte> vmiklos: two, it was written in Python
01:33 < gitte> vmiklos: three, it did not define a language, but a
                     class interface
01:33 < gitte> vmiklos: four, it made assumptions about the internal
                     organization of SCMs
01:33 < gitte> vmiklos: five, it is maintained in a darcs repository,
                     which tailor cannot even convert to Git.
01:35 < gitte> vmiklos: oh, and it did not help that the configuration
                     is awkward and badly documented, not to mention
                     inconsistent with regard to the types of input/output
                     repositories.

OK, given that I want to build the Git User Manual 1.6.1-rc1 with Asciidoc 8.3.0, I continue the story started yesterday. The new bug seem to have something with attribute handling, whitespaces in references and quotes, pick your favorite one.

So today I had a test at the uni with a lot of formula and given that it was boring to learn, I created a cheat sheet using asciidoc. The fun part is that the just released asciidoc 8.3 not only supports inline tex expressions but (using -a latexmath) supports rendering most of them to html as well.

I bookmarked a few related useful howtos on delicios, and my 14-page-length doc is available here (source, pdf, html).

I also like the new table format. The only buggy thing seems that I always have to scale images down, 100% results in a size about 200% somehow. Ah and the url escaping stuff I just reported, but that's not a problem here.

I hit it while building Git v1.6.1-rc1, released today. The toplist of that is interesting:

$ git shortlog -s -n v1.6.0..v1.6.1-rc1|head
   351  Junio C Hamano
    61  Alexander Gavrilov
    54  Shawn O. Pearce
    48  Miklos Vajna
    43  Jeff King
    38  Brandon Casey
    29  Nanako Shiraishi
    28  Nicolas Pitre
    25  Alex Riesen
    24  Petr Baudis

Heh, heh.

OK, I gave up converting darcs' darcs with tailor, opened a ticket for it. Once that is resolve, I hope I can do a comparision.

Snip. I like the new asciidoc-8.3.0, now math expressions can be defined using the latexmath :: [] macro inline. ;-)

Snip. I like how people can say the usual "if you need it, send a patch" sentence. Today's version:

"It's not very high on my list of priorities, but I assume fixing the problem is probably not hard if you decide to get your editor dirty." :-)

(full message)

I just sent this patch, because I hated I had to look up the source about what -b does.

BTW, I did the d-f-e benchmark for the ghc repo as well, the results are here. I hope I can get tailor to somehow convert the darcs and ghc darcs repo as well, then I can draw some nice chart about how fast d-f-e is. ;-)

Currently it can't convert darcs.darcs because I specified latin2 as input/output charset and it considered that as invalid. Given that d-f-e detected ISO-8859-2, I wonder WTF is this, I unspecified the output charset and changed latin2 to ISO-8859-2 on the input side, we'll see if that helps or not.

I got to implement the direct patch technique for darcs2 repos in darcs-fast-export, and it seems to be a dramatic speedup.

The benchmark was done using darcs' darcs.

Before:

real    786m16.035s

After:

real       29m39.458s

I plan to do a similar benchmark with ghc's darcs repo as well (it contains about 19k patches).

So today I did what I have in my TODO for some time: make darcs-fast-export produce the fast-import stream on the fly, without a tmp working dir (that's how tailor and darcs2git works, and I think that's just ugly).

And the result? I thought this will be the trick that makes it a lot faster, compared to tailor and at the end it turns out that it slows it down about 3 times. :-(

Not counting speed issues, it's a huge cleanup:

 12 files changed, 34 insertions(+), 106 deletions(-)

Dunno what to do with it now. I'll try to poke the darcs devs, maybe they can optimize it a bit.

The sad fact is the comparision to git:

$ time darcs show contents --match "hash 20040523231834-97f81-2bca6242bec169bd01079378524a33e0310e0b65.gz" tailor.py >/dev/null
real    0m2.780s
$ time git show 451ae1176d56a579d3d7bd236fe7d7dd9df59326:tailor.py >/dev/null
real    0m0.004s

OK, so I got this idea in the darcs-user mailing list that it would be nice to do some benchmarks on how fast and correct darcs-fast-export is. Actually I already have a TODO item about an idea that would make it faster, but doing a benchmark before doing the speedup is required in that case as well, so that I can show "hey, this is cool, it results in foo% speedup!11". ;-)

And if I'm already there, I plan to do it with tailor as well, I'm just curious about how fast it is. Ideally fast-import is much faster, but I guess the current darcs exporter does not make use of it, so I expect something like 1:1 for now.

The test repo is darcs' darcs, current status with darcs-fast-export is like:

progress [2008-11-25 16:02:28] getting list of patches
progress [2008-11-26 00:53:25] 4000/6548 patches

Yeah, darcs apply is slow.

I got this exercise at the uni, and I thought it's easier if I split the problem: first the logical one (implement the pseudocode from Wikipedia in Python) then the RTFM one (figure out the right Java API).

Of course I wasted the whole evening by not starting working on it, so it was 0:30 when I started. It took about 2 hours to do the Python implementation, and then again two hours to transform it to Java. And of course the code is two times longer. Guess what? One of the guy I talked today was surprised about how short my Java code is. :-P

BTW, the day before I finally got to write git-darcs. An old vision that is now reality. :-)