[darcs-users] Colin Walters blogs on Arch changesets vs Darcs
droundy at abridgegame.org
Wed Nov 24 13:17:20 UTC 2004
On Wed, Nov 24, 2004 at 05:33:23PM +1000, Anthony Towns wrote:
> Colin Walters wrote:
> >On Wed, 2004-11-24 at 16:12 +1000, Anthony Towns wrote:
> 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.
Yeah, I've thought about this in darcs, but since darcs requires that
patches be invertible, you'd have "interesting" challenges dealing with the
"merge two identical files" patch that is the inverse of the cp patch. And
of course there are the usual interesting commutation questions. I suspect
that there may be a way to do this usefully and correctly, but it'd take
An interesting problem that has related applications (and related
difficulties) is the cross-file-hunk-move patch. Of course, first one
would want to implement an intra-file-hunk-move patch (I did this once, but
that was ages ago), but the cross-file-hunk-move patch would be cool, since
it would let you move a function from one file to another, and any
modifications to that function would be merged into the new file without
conflict. The problem (of course) is that when conflicts happen, you have
a royal mess. Plus, of course, figuring out commutation is a mess, too.
For about half the uses of a "cp" patch, what you'd really want is a
cross-file-hunk-move patch, since what you really want is to simply split
the file into two. The other instances are where you want a certain header
(e.g. the GPL copyright header) duplicated in many files, so you'd like to
create all your new files with a "cp blank_file.cpp foo.cpp" so you can
later change the copyright by only modifying the "blanck_file" and then
merging the patch.
> >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.
Indeed, this is the real trick for darcs to scale fine, since it means you
only need the history back to the most recent common tag. If you're
talking about xemacs and emacs, this won't do you much good, but if you're
talking about something like linux, where everyone syncs up with the
mainline tree from time to time, there's no reason there need be poor
> 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.
Indeed, these are the two main problems. I've been trying (when not
distracted by interesting emails by people like you, or bugs in annotate)
to work on the conflicts issue. Alas, the very clever idea I had leads
isn't possible (not internally consistent), so I'm back to the drawing
boards. The trouble is that dealing with conflicts with conflicts with
conflicts requires some interesting mental gymnastics.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041124/1d601945/attachment.pgp
More information about the darcs-users