[Haskell-cafe] fptools in darcs now available

David Roundy droundy at darcs.net
Sat Apr 30 09:12:04 EDT 2005

On Fri, Apr 29, 2005 at 08:38:05AM -0500, John Goerzen wrote:
> On Fri, Apr 29, 2005 at 10:39:13AM +0100, Simon Marlow wrote:
> > So, here's two potential solutions:
> > 
> >   1. Make it possible to 'darcs get' just part of a tree.  Patches
> >      that don't touch any files in the "live" parts of the tree
> >      are discarded.  (I don't know if this is possible, or how
> >      difficult it is).
> That's an interesting question.  It's not a darcs feature now, but I
> also don't know how hard it is.

It's hard, but maybe not impracticably hard.  We'd need to store an index
of which patches affect which directories (and perhaps files).  And we'd
need to modify the application of patches to work when parts of those
patches can't be applied (because they apply to files or directories which
aren't present.

On the plus side, the index of patches affecting files and directories
would be hugely useful for speeding up annotate, whose slowness is a
moderately common complaint about darcs, so this part of the work wouldn't
necesarily be "wasted".  And in fact this could be done and tested and used
independently from the "get part of a tree" feature.

The second idea is a bit weirder and more contrary to darcs' philosophy.
Perhaps this could be done using stubs to indicate that the file isn't
present.  You run into trouble when there is a patch

move ./foo/file ./bar/file

if the foo directory isn't present, but the bar directory is.  If we
carried around stubs of some sort (a non-portable implementation idea would
be a symlink to "MAGIC_DARCS_STUB_WORD"), we could just add a "not present"
stub as ./bar/file, and let the user yell at whoever moved a file between
"modules".  Or perhaps there'd be a way to "check out" the directories or
files you don't have present, which you could use when you see stub files
showing up in your desired directories.

> >   2. Create separate repositories for GHC, Happy, Haddock etc., and
> >      duplicate the shared fptools structure in each project.  Each
> >      time we modify something in the shared part of the tree, we
> >      pull the patch into the other trees.  (is it possible to
> >      cherry-pick from a tree that doesn't have a common ancestor?
> >      If not, can we make the repositories appear to have common
> >      ancestry?).
> No, you can't cherry-pick if there's no common ancestor, but you can
> make this appear to have a common ancestor.  The idea is basically to
> start each one from a repo that has only the common parts, in their own
> directory, and then merge in the relevant patches to make each unique
> project.  I do that with my sgml-common system, which is a set of
> scripts and support for building documentation and manpages from DocBook
> SGML sources.  I use it in several of my projects and it works well.

Yes, this is a nice way of doing things.  The catch is that it all breaks
down when someone records a patch that touches both the common parts and a
specific part.  Perhaps a clever script could check for such a scenario and
reject those patches.  A *seriously* clever script (hook in darcs?) could
prevent it from happening in the first place, which would be best.
David Roundy

More information about the Haskell-Cafe mailing list