[darcs-users] Colin Walters blogs on Arch changesets vs Darcs
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:
Then later, you want to stick this all in a subdir:
And you create a new file, project/Makefile, the contents of which are
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
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