[darcs-users] the centralized nature of darcs
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
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.
More information about the darcs-users