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

Anthony Towns aj at azure.humbug.org.au
Wed Nov 24 06:12:04 UTC 2004

Colin Walters wrote:
> 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.
> project/
>   Makefile
> The contents of Makefile are solely:
> include $(top_srcdir)/Makefile.common
> Then later, you want to stick this all in a subdir:
> project/
>   Makefile
>   foo/
>     Makefile 
> And you create a new file, project/Makefile, the contents of which are
> still just:
> include $(top_srcdir)/Makefile.common

> 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!

The same thing happens in arch, no? ie, the newly created Makefile might 
have the same contents, but it's a different logical file, so patches 
against the original Makefile don't go to the right place.

The way to handle it in darcs is via:

    $ mkdir foo
    $ darcs add foo
    $ for a in Makefile foo.c bar.c; do darcs mv $a foo/$a; done
    $ cp foo/Makefile ./Makefile
    $ darcs add Makefile
    $ darcs record -p 'move sources to subdir'

Then when you get a patch against the original release, darcs will first 
commute it with the 'move sources to subdir' patch, which tells it that 
the original Makefile moved, and so any hunks against the original 
Makefile will be changed to apply to the new location for the Makefile 

 > I don't see how you can solve this
> without a notion of explicit logical file identity.

ObVious: with an implicit notion of logical file identity :)

> 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.  

For comparison, I like darcs because it's really simple, so adding merge 
operators to Arch doesn't seem like a win in any way to me :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041124/615b334b/attachment.pgp 

More information about the darcs-users mailing list