[darcs-users] Colin Walters blogs on Arch changesets vs Darcs
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...
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