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

Anthony Towns aj at azure.humbug.org.au
Wed Nov 24 07:33:23 UTC 2004

Colin Walters wrote:
> On Wed, 2004-11-24 at 16:12 +1000, Anthony Towns wrote:
>>The same thing happens in arch, no? 
> Arch will handle it, because the changeset will be against the logical
> id of the original foo/Makefile.

Right, but only because you told it the Makefile moved, rather than 
copying it (and foo/Makefile thus being a "new" file).

>>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.
> Arch doesn't refer at all to file contents for this, except for looking
> for an arch-tag: header if the project has enabled that.

Right - darcs doesn't look at the contents at all either for this.

>>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'
> Very similar in Arch.

Yup. I was looking at some VC comparison page google tossed at me 
yesterday that suggested some VC systems would let you do a "cp" 
operation that'd give you two files with the same history, which is an 
interesting concept too.

>>Then when you get a patch against the original release, darcs will first 
>>commute it with the 'move sources to subdir' patch, 
> I guess this is what I didn't quite get at first; how does Darcs know to
> commute it?  The answer is apparently provided by Quag, in that some
> sort of history is sent along with the patch.

Patches have context, basically. Like a unified diff -- it doesn't just 
add the line "Foobar!", it tells you what the rest of the 
file/repository is meant to look like before you do that. The difference 
is that darcs can "commute" patches so that they can be applied to the 
same effect in different contexts; and the context is just a series of 
patches beginning with "darcs init". So if you have "I, A, B, C, X"; you 
can commute that to "I, A, X', B', C'", then drop/invert C' and B' to 
have "I, A, X'", and then merge that with a repository containing "I, A, 
D" to get "I, A, D, X''".

Each step is just taking the same patch and moving it to a new context.

(Hrm, "recontextualising" might be a better term than "commuting" or 

> I think it would be much harder for Darcs to gain
> the notion of archives.

darcs explicitly doesn't have the (tla) notion of archives; that's a 
feature, not a bug. What it has instead is "tags", which are global (by 
email address, time of creation, and name -- email address and time of 
creation give most of the global uniqueness).

Of course, I wrote "darcs-repo" which is about adding a notion of 
"archives" to darcs, so I guess I shouldn't talk :) Anyway, it in 
particular allows for a single archive that contains many branches for a 
project, doesn't allow unrecords, and is reasonably cheap (it's in perl, 
and doesn't have any recursion/exponential paths etc). It'll get renamed 
to "darcshive" as soon as I can work out why my copy of darcs doesn't 
seem to recognise remote ssh/scp repositories :(

> My fundamental point (that you trimmed from
> your reply) is that it seems to me that Darcs cannot scale in its
> current form.

So darcs' technique for "scaling" is to use TAGs to imply all the 
context. So the tag "DARCS-REPO-0.3" implies a dozen patches, and 
"DARCS-1.0.0" probably implies thousands. As long as the repository 
you're trying to apply the patch to has that tag, you can basically just 
ignore all of those thousands of patches, because you don't need to 
commute around them.

AIUI, the main reasons darcs doesn't scale well is that it doesn't have 
great alogrithms for dealing with conflicts (they go exponential), and 
that it's a memory hog when dealing with large individual patches. But 
those are "doesn't scale" not "cannot scale", ttbomk.

-------------- 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/b04caba2/attachment.pgp 

More information about the darcs-users mailing list