[darcs-users] reviewing and testing pulls

David Roundy droundy at abridgegame.org
Mon May 3 10:50:51 UTC 2004

On Fri, Apr 30, 2004 at 11:57:04AM -0400, Andrew Pimlott wrote:
> On Fri, Apr 30, 2004 at 05:18:48AM -0400, David Roundy wrote:
> > As long as the necesary reordering is possible, you can acheive this
> > simply by unrecording and re-recording, which is what I'd recommend
> > doing.  Don't want to have too many commands (or does darcs already
> > have too many commands?)...
> Perhaps, but if you ever get worried about that, just go look at arch!
> When I read the tutorial, I was shocked that a "new, better" rcs would
> have so much complexity.  darcs seems to me both more advanced and much
> simpler, and I don't feel that I'm giving up anything for that
> simplicity.  Instead, I'm gaining flexibility and ease of use.
> Seriously, can a good case be made for the complexity in arch?  Am I
> missing something?  Sorry if this question is too vague or off-topic.

I'd say there are a few reasons for the complexity in arch.

The first is that Tom decided to implement all sorts of "interesting"
functionality in arch, like supporting version numbers, branch naming, etc
all within a single arch repository, which means one needs commands to
query and modify all those objects.  Also, arch supports several levels of
interaction--between two branches within a repository, between two branches
within different repositories, and between a working directory and a
repository--all of which require either different commands or that the same
commands be able to do something rather different.

On top of the above, the lack of a coherent patch theory means that there
is no capability in arch of performing a true merge (meaning a symmetric
merge).  Instead, the primitive in arch is inexact patching, which means
that you get a different final result depending on the order in which you
perform a set of merges--thus the many many ways arch supports merging.
Tom sees this as a "feature", but I (obviously) see it as the result of a
flawed paradigm.

Thus darcs.  :)
David Roundy

More information about the darcs-users mailing list