On Thu, Oct 13, 2005 at 04:28:44PM -0700, John Meacham wrote: > On Thu, Oct 13, 2005 at 08:35:35AM -0400, David Roundy wrote: > > Another idea that I discussed at length with Ravi over ICFP is adding > > native darcs support for nested repositories. The main idea is to add a > > set of primitive patch types that operate on subrepositories. We'd have > > primitive patch types such as: > > > > darcs init ./subdir > > darcs record ./subdir (FOLLOWED BY PATCH CONTENTS) > > darcs obliterate ./subdir (FOLLOWED BY PATCH CONTENTS) > > > > where obliterate is the inverse of record--perhaps we'd be better off with > > nicer names like "darcs addpatch" and "darcs removepatch". > > > > In any case, the idea is that the nested repos are just ordinary > > repositories, but the parent repository will contain duplication of all the > > information in the children, so that when you pull the parent you'll also > > get copies of all the child repositories. > > > > This scheme would allow us to have atomic commits across subrepository > > boundaries, which is something neither of the two already-possible schemes > > would allow. It also is backward-compatible with the scheme described by > > John, in if we ever implement these features, we can take existing > > nested repositories and add them to the parent repositories as > > subrepositories without losing history. > > so, patches that cross subrepo boundries will automatically be split into > multiple patches? or a subrepo will know to ignore the bits that affect > other repos?
Each subrepo will have its own set of patches (which are distinct patches from those of the parent repo, having distinct IDs). So the patches applied to subrepos will be patches recorded for that subrepo. There are different levels of integration that we could implement, but that integration would really be a user-interface question, not a darcs-internals (or repository format) issue. As a first implementation, I'd probably require that you run record separately in each repository. You'd record your changes in all the subrepos first, and then when you run record in the parent repo, it would prompt you for all those patches as possible patches to record. The parent repo would treat subrepos as a sort of strange type of file, which have a different set of patches to modify their state. Once the idea is working, we could go to the trouble of making whatsnew, record, revert and unrevert work on the entire ecosystem. This would mean that record might end up creating several patches at once--each in a different repository. But you'd still need the ability to run record in a single subrepository only. > > I think the ideas to implement this are all in place, it just requires > > someone with a month or so to implement it. > > This sounds interesting. > > The solution I was thinking of involved just adding a property listing > a set of 'subrepos' and have darcs get,put,push,pull,record recurse into them > unless a --norecurse option is given. The major difference between my idea and your (user-interface-change-only) idea is that my plan would allow atomic commits across repositories. It would also allow test suites that handle versioning across repositories, so if the test suite were in a subrepository and the code in another, one could set up a workflow in which you couldn't record (or couldn't push) changes that caused the test suite to fail--which requires atomic commits across repositories. Ravi's work includes such a scenario (where the code is big enough that including the testsuite with each "get" of the code is unreasonable--especially if using darcs to deploy the code to clients). -- David Roundy http://www.darcs.net _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
