The Darcs Revision Control System [LWN.net]

The Darcs Revision Control System

Posted Nov 11, 2004 16:10 UTC (Thu) by hmh (subscriber, #3838)
In reply to: The Darcs Revision Control System by zooko
Parent article: The Darcs Revision Control System

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...

(Log in to post comments)

The Darcs Revision Control System

Posted Nov 11, 2004 17:25 UTC (Thu) by larryr (guest, #4030) [Link]

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

Posted Nov 11, 2004 20:06 UTC (Thu) by bfields (subscriber, #19510) [Link]

> 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

Posted Nov 12, 2004 4:06 UTC (Fri) by ncm (subscriber, #165) [Link]

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

The Darcs Revision Control System

Posted Nov 12, 2004 18:37 UTC (Fri) by larryr (guest, #4030) [Link]

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