[darcs-users] Colin Walters blogs on Arch changesets vs Darcs

Zooko O'Whielacronx zooko at zooko.com
Wed Nov 24 15:06:26 UTC 2004

On 2004, Nov 24, at 03:33, Anthony Towns wrote:

> Colin Walters wrote:
>> My fundamental point (that you trimmed from
>> your reply) is that it seems to me that Darcs cannot scale in its
>> current form.
> So darcs' technique for "scaling" is to use TAGs to imply all the 
> context. So the tag "DARCS-REPO-0.3" implies a dozen patches, and 
> "DARCS-1.0.0" probably implies thousands. As long as the repository 
> you're trying to apply the patch to has that tag, you can basically 
> just ignore all of those thousands of patches, because you don't need 
> to commute around them.
> AIUI, the main reasons darcs doesn't scale well is that it doesn't 
> have great alogrithms for dealing with conflicts (they go 
> exponential), and that it's a memory hog when dealing with large 
> individual patches. But those are "doesn't scale" not "cannot scale", 
> ttbomk.

I think you two are talking about two different things when you say 
"scaling".  Or if you're not, you ought to be!

1.  One issue is that darcs uses information about a lot of different 
patches when doing a darcs get.  Therefore it requires a huge amount of 
RAM.  Or something like that.  I hardly care about this issue so I'm 
not sure about the details.  Issue #1 could be called a problem with 
darcs "scaling" in terms of the amount of memory required for a darcs 

2  The other issue is that people who share source code in a certain 
project are required to have a shared darcs-history.  This imposes two 

(2.a) every single contributor to the shared source must use darcs, or 
if any contributor does not use darcs then all contributors who do use 
darcs have to agree on a single, centralized, manual mechanism of 
integrating the non-darcs-user's patches,

(2.b) even if two different contributors or groups of contributors are 
using darcs -- for example if all contributors to GNU Emacs and all 
contributors to XEmacs both decide to adopt darcs today -- they still 
have to manually reconstruct the entire history of any patches that 
they want to share.  I really doubt that this is possible.  I've had 
great difficulty doing this with the Shtoom codebase, which is stored 
in a relatively new revision control system (SVN) and which is only a 
year or so old, and which has only one main branch (no forks or 
branches) (excepting my own patches).

Issue #2 could be called a problem with darcs "scaling" in terms of the 
number and diversity of hackers who are going to share source code.

The problem of storing the entire history of the patch in RAM while 
manipulating the patch (issue #1) is separate from the issue of 
*finding* the entire history of the patch (issue #2.b), and of 
generating a shared darcs-representation of that history (issue #2.a.).

I care very much about Issue #2 and only a little about issue #1.  My 
mistaken belief that darcs was better for decentralized sharing of 
source code was why I started using darcs in the first place.



More information about the darcs-users mailing list