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 http://www.darcs.net