[darcs-devel] Can someone take a look at issue124?

David Roundy droundy at darcs.net
Thu Feb 16 06:27:17 PST 2006


On Sun, Feb 05, 2006 at 11:49:29PM -0800, John Meacham wrote:
> On Sun, Feb 05, 2006 at 02:52:01PM -0500, David Roundy wrote:
> > Simon pointed out an optimization that we really ought to be
> > doing--keeping track of which files modify which patches to make
> > changes and annotate much faster when looking at a particular file.  I
> > think this is an important job of moderate complexity that any of a
> > number of you guys could tackle if you're interested.  It's a chance to
> > do darcs optimization without having to understand the trickinesses of
> > optimization in Haskell, since you'd be doing algorithmic optimizations
> > rather than code tuning--and that's where all the real benefits are to
> > be gained anyways (except for space optimizations...).
> >
> > I just figured I'd float a note here to see if anyone cares to
> > volunteer for this project.  You'd need to be (or be willing to become)
> > a real Haskell programmer, but wouldn't need to understand all the
> > details of darcs.  Part of the job (optimizing changes and annotate)
> > could be done bit-by-bit, which should make it a bit more tractable
> > than would otherwise be the case.  The only real trickiness that I see
> > is in handling file renames properly, and I can see at least two ways
> > to handle that (which is what makes it potentially tricky).
> 
> Actually, doing this would be an integral part of implementing my
> 'domains' proposal (efficiently) that was discussed on the darcs-users
> list recently. If you think they are a good idea, I could tackle this as
> well in the process.

I just took a look at your domains proposal.  It looks
appealing--particularly because it doesn't affect any of darcs' internals,
so we could always scrap the idea if it doesn't work out as well as
expected.

I do have some reservations regarding how domains will interact with
renames, and with the fact that domains can change freely.  It's
essentially an uncontrolled (from darcs' standpoint) way of classifying
patches, so unless the users maintain their domain file properly, things
could get hairy.  But darcs certainly has many other mechanisms by which
users can shoot themselves in the foot, so this isn't something new.

I imagine the only interface change will be the --domain flag to many
commands, and probably an --ignore-domains/--enforce-domains pair to
apply/mv/record/pull etc?  To me, that seems all right for an experimental
feature that could be reverted later if it's deemed too confusing and
unuseful.  And we'd want a section in the manual outlining what domains
are, and probably a link to it from all the affected commands.

Keep in mind that just because I like the idea doesn't mean it's going to
be accepted.  For true subrepos I definitely prefer the subrepo patch idea,
but that's a heavyweight solution, and as you've pointed out, domains could
be useful for other purposes.

I don't really like Tomasz's idea of making the domainfile possibly be a
script.  That seems like it could make the whole scheme too fragile.
A similar effect could be achieved by having a Makefile that autogenerates
the domainfile.  It's hokier, but not too bad, and I'm not sure how useful
the scripting idea would be.

Another warning.  You'll have to be careful with --ask-deps and domains,
since a patch recorded in one domain can't depend on patches in any other
domain.
-- 
David Roundy
http://www.darcs.net




More information about the darcs-devel mailing list