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

Colin Walters walters at verbum.org
Tue Nov 23 23:13:34 UTC 2004

On Mon, 2004-11-22 at 03:48 -0500, Andrew Pimlott wrote:

> I think another poster answered this, but let me stress:  A darcs patch
> cannot fail to apply (assuming its context is in the target repository)!

Suppose that you have a setup like this.


The contents of Makefile are solely:
include $(top_srcdir)/Makefile.common

Then later, you want to stick this all in a subdir:


And you create a new file, project/Makefile, the contents of which are
still just:
include $(top_srcdir)/Makefile.common

However, suppose that in between these two trees, someone notices that
the project/Makefile in the first tree requires a line:

HEADERS = foo.h

They create a darcs tree, and create a patch.  Meanwhile, upstream has
moved onto the second tree.  When they receive the patch, it will apply
exactly to project/Makefile, because they have the same content.  But it
will be the *wrong* Makefile!  I don't see how you can solve this
without a notion of explicit logical file identity.

> However, you can exclude the patch files themselves from a repo (this is
> the checkpoint and partial get features).  This makes operations that
> need those patches fail, which usually is not a practical problem.  

The issue is "usually".  You don't want operations to randomly fail
because I didn't happen to check out enough history.  Moreover, it seems
to me that when you *do* do an operation like this, it forces everyone
to check out back to that earlier patch.

> > I think that characterizing this as simply "performance" is a bit
> > disingenuous.
> It's a defense mechanism from being on this list too long.  These are
> hard problems and I wish I had more time to work on them.

It's not just that this is a "hard problem".  I just fundamentally don't
see how it can scale in general.  For small projects, sure.  But
something like gcc or Emacs or Linux?

> I'm not sure quite what you mean.  It seems like (if you don't have any
> fancy indices) you just have to scan linearly through the patches
> looking for ones that affect the relevant file.  With darcs, you just
> have to keep track of that file's current name.  Maybe I misunderstand
> your example.

Ok, that would probably work, yes.

> But there will probably inevitably be cases where darcs doesn't scale as
> well.  I think darcs is truly an experiment in this regard, but a very
> promising one.

Darcs is very cool, don't get me wrong.  I've certainly learned a lot
from it.  But it seems to me that the best of both worlds is Darcs'
merge as an option in a system like Arch.  

> Watch it, we don't take kindly to mutation around these parts!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041123/97d9891f/attachment.pgp 

More information about the darcs-users mailing list