[darcs-users] Colin Walters blogs on Arch changesets vs Darcs
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",
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