Re: [darcs-users] Re: Git-aware Darcs: a tutorial

It depends very much on the command, but in general it's no faster than plain Darcs right now, except for accessing the working directory when you have an up-to-date cache. The nice thing, of course, is that since Darcs-git works on pure Git repositories, you can always switch to using plain Git commands when an operation is likely to be too slow, as I've done in the example above.

(Editor's note: ``Patch'' is Darcs-speak for what BK calls a Changeset.)

Commands that only touch the working dir and the top of the history -- darcs what, darcs record, and so on -- are relatively fast; unlike the native Git equivalents, they stat every file in your tree (I'll be fixing this RSN), but they don't touch the contents of unchanged files. Darcs whatsnew on a full kernel takes 4s on my machine.

Commands that read history (darcs changes, darcs send, darcs push) are very fast until they encounter a merge, as they need to read the full contents of one of the two branches (just the changed files, of course). In practice, that means that doing |darcs whatsnew| gets me the last 90 patches in Linux' history in a few seconds, then stalls. I've tried to track the problem down, but after an afternoon of work I had gotten no further. (I've explained the issue in excruciating detail on Darcs-Devel, if you're interested.)

Commands that push patches around scale rather badly with the amount of files touched by a patch. In practice, this means that you'll be able to push around all patches in a kernel tree in a reasonable time, except for the initial commit (220MB of touched files), which you can only push using the native Git tools.

And then there is what I consider as the actual showstopper: darcs diff is completely brain-damaged (very much so in plain Darcs, even more so in Darcs-git). It needs a complete rewrite.

                                        Juliusz