LWN: Comments on "The Darcs Revision Control System"

database format

stevenj — Fri, 12 Nov 2004 22:48:01 +0000

All of the Darcs data is stored in a _darcs subdirectory of your project. The revisions are stored as a subdirectory full of gzipped patch files. The rest of the data (lists of changelog comments, preferences, etcetera) are stored in plain text files.

The Darcs Revision Control System

giraffedata — Fri, 12 Nov 2004 22:02:34 +0000

What does the database look like? I don't like things I can't patch up with Emacs, or process with other standard text tools, if I get desperate.

The Darcs Revision Control System

larryr — Fri, 12 Nov 2004 18:37:22 +0000

I think the performance problems with darcs may be related to deriving metadata information at runtime rather than storing it explicitly in files or filenames; in other words the fundamental approach is resource intensive rather than the particular implementation.

Larry

The Darcs Revision Control System

ncm — Fri, 12 Nov 2004 04:06:17 +0000

Memory management for substantial programs written in garbage-collected languages is always tough.

The Darcs Revision Control System

bfields — Thu, 11 Nov 2004 20:06:15 +0000

> Is that memory usage swap-friendly?

From his post to lkml announcing the darcs mirror of linux

"Be forewarned that darcs is a bit of a memory hog when run with large
repositories, so the above command may take quite a while, and probably
will require 700 or 800 megabytes of virtual memory. The actual working
set of memory is under 300 megabytes. Work is underway to improve both the
speed and memory usage of darcs."

The Darcs Revision Control System

larryr — Thu, 11 Nov 2004 17:25:07 +0000

I think maybe it should be called "darcs beta 1.0" because there are several ways in which not only is it not really ready for widespread use, but it is not clear to me how it is going to get there.

But I hope it will, because I prefer it to the way arch has been so far, and I tend to think there will only be one dominant patch-oriented open source solution.

Larry

The Darcs Revision Control System

hmh — Thu, 11 Nov 2004 16:10:12 +0000

Eek!

Is that memory usage swap-friendly? If so, that's not so bad since 1GB of swap area is not too much (I have a lot more, as backstorage for tmpfs anyway, I assume many do the same on their development boxes)...

But still, it is quite non-scalable...

The Darcs Revision Control System

zooko — Thu, 11 Nov 2004 13:56:48 +0000

Oh, and another known issue in darcs v1.0 is that the initial "get" (equivalent to a cvs "checkout") stores the entire history in RAM at one point. For example, I'm now doing a "darcs get" on the Linux kernel, and it is using 504 MB virtual...

After I've finished this darcs get, I'll subsequently be able to do "darcs pulls" to update the kernel source while using only an amount of RAM proportional to the new patches that I'm getting.

The Darcs Revision Control System

zooko — Thu, 11 Nov 2004 13:50:43 +0000

I'm a fan of darcs. I tried it out after writing my http://zooko.com/revision_control_quick_ref.html, and I've been using it ever since.

v1.0 still has a few known issues. Certain pathological (or at least confused) behavior on the part of the user can cause darcs to get into a "wedged" state that requires careful correction in order to recover. That's the worst outstanding problem in darcs as far as I know.

Of interest to LWN subscribers, there is a darcs mirror of the Linux kernel:

http://darcs.net/linux.html

I think the darcs land view of the kernel is losing historical information because it is going from BitKeeper to CVS to darcs. So for example although BitKeeper and darcs both handle file renames properly, CVS doesn't so that information gets lost.

Maybe someone who is legally allowed to use BitKeeper could set up a better mirror into darcs land.

Regards,

Zooko