[Gnu-arch-users] Re: darcs vs tla

[Catalin Marinas]

Timothy Webster <address@hidden> writes:
> I would like to hear from users who have tried both tla and
> darcs. And specifically why I should not go with darcs.

I tried darcs and I like the patch commuting theory (though I have a
slightly different opinion about some patch dependency cases). The
main problem with it - it is incredibly slow. I tried it with the
Linux kernel (~300MB sources) and the commit operation (after applying
an 18MB patch) took around 3 hours, in which time my machine was
completely unusable. Darcs memory usage is about twice the size of all
the patches in the repository (including the initial import),
i.e. around 600MB for the kernel tree with only one patch applied.

This memory usage is because darcs loads all the patches into memory
at a simple merge operation in order to track the dependencies. The
patch commuting can be performed using only the line numbers a hunk
modifies and only reading the text when the patch is applied but the
current repository structure does not allow this (and I don't know
whether David Roundy wants to break the compatibility with the
existing structure or not). Even if this would be implemented, more
engineering needs to go into it before it could cope with the level of
patches in the Linux kernel (around 50 patches a day).

A second problem I think is Haskell. Not so many people can help with
coding and it is also much slower than C or C++. The today's compilers
are not smart enough to optimally deal with pure functional
languages. I was told to compile it with some options like
--enable-antimemoize which would reduce the memory usage but it needs
to parse the patches several times. The generated code also seems to
forget to do garbage collection. You can force it but specifying a
maximum memory usage but you might never get it right (and see after
an hour that it exits with "not enough memory").

With darcs you also need to understand its theory of patches since it
doesn't report a conflict for cases where arch does (this is where I
think darcs should at least let you know). Arch's patches are more
readable since they are based on the diff format.

While darcs is a nice research project, my recommendation would be to
stay with arch, at least until you hear somebody happily using darcs
with a huge source tree like the Linux kernel.

Hope it helps,

Catalin