[darcs-users] the centralized nature of darcs

Zooko O'Whielacronx zooko at zooko.com
Sat Nov 20 10:14:39 UTC 2004


I'm very glad that Colin is focussing attention on this important point.

My current belief is that darcs is "not fully decentralized", inasmuch 
as common history is required.

The XEmacs vs. Emacs example is a good one.

A more immediate example of the same problem -- one that I struggle 
with every week -- is what happens if some hackers are using darcs and 
others are using other source control mechanisms.  In the project I'm 
currently working on it is a common problem that some source code gets 
entered into darcs twice.

For example Alice (not using darcs) wrote a patch, sent a copy to Bob 
(not using darcs) and Charles (using darcs).  Bob made a small change 
to the patch and sent a copy to his friend Diane (using darcs).  Now 
Diane and Charles each have a darcs repo and they share darcs history 
with one another.  However, when Diane and Charles each independently 
commit the patch to their darcs repo and then attempt to sync their 
repos together, darcs enters an O(N^2) algorithm attempting to deduce 
how these two very similar patches fit into its notion of history.  It 
never completes this analysis, so Diane and Charles have to interrupt 
their darcs processes, stop all work which depends upon this patch, 
contact one another via e-mail and agree that one of them will enter 
the patch in his or her darcs repo, then the other one will erase his 
or her version of the patch from his or her darcs repo's history, then 
pull that patch from the other one, then manually re-apply the change 
that Charles's friend Bob made.

This is, in a word, *centralized*.  Nobody who uses any darcs repo 
anywhere in the world can safely hack on that patch until they have 
*first* synced up with Charles's (or maybe Diane's -- they haven't 
decided yet), repo.

This would be disturbing to me in theory, but it is even more 
disturbing since it bites me in practice just about every week.  
Fortunately the project I am working on is currently small enough that 
I can work around the problem by manually doing the steps outlines 
above.

Not to put too fine a point on it, but now that I've come to appreciate 
how deeply this issue is ingrained into the darcs design, my enthusiasm 
for darcs has begun to ebb.  Certainly darcs has many fine qualities, 
and any revision control system that I use (or write) in the future 
will have to adopt many of those elements, but currently I can 
recommend darcs only for centralized hackery, not for decentralized.

Regards,

Zooko





More information about the darcs-users mailing list