[darcs-users] Re: darcs'ing fptools

[David Roundy]

On Tue, Oct 11, 2005 at 09:22:24AM -0500, John Goerzen wrote:
> It is possible to have nested darcs repos.
...
> The usual method here may look like this:
> 
> 1) User runs darcs get http://darcs.haskell.org/ghc (or smilar)
> 
> 2) This repo contains a script, say getall.sh that is run from inside
>    this new ghc directory.  It will darcs get whatever else is needed.

I should mention the other mechanism for approximating nested
repositories.

You can have a "libraries" repository which contains a single subdirectory
named libraries/ in which all its files reside.  This repository can now be
pulled without conflict into any other repository (for example, ghc) that
doesn't contain a directory named libraries/.  If every change that
modifies the contents of libraries/ *only* modifies the contents of
repositories, then those changes can be pulled from ghc into libraries.
Libraries can then be used either on its own or pulled into any other
repository.  Note that ghc *can* safely rename or move the libraries/
directory without messing the whole scheme up.

The main downside of this scheme is that it requires discipline to ensure
that you never record a change that affects both libraries/ and some other
directory.  And it's more than a bit artificial, since libraries now has to
have a subdirectory, so when someone just darcs gets libraries, they've got
an extra level of directories that's a bit ugly.

The main upside of this scheme is that tags reflect the contents of all
subdirectories, so you have a simple way of reproducing "the entire ghc
tree (libraries included) when ghc 6.6.0 was released".


Back to John's explanation of the "true" nested repository method:

>    (There should also be an accompanying pullall.sh that will pull down
>    updates from the remote)
>
> 3) Whenever changes are made, they are darcs recorded like usual.
> 
> 4) Whenever changes are sent upstream, users must make sure to run
>    darcs send or darcs push from the appropriate directory.
>    
>    (Otherwise, changes may be missed.)

You might also want pullall, sendall, pushall etc scripts.

> Does that make sense?  (And to other darcs folks: I'm not smoking
> something here, right? <g>)

Yeah, that's one of the two currently-practical methods.


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.

I think the ideas to implement this are all in place, it just requires
someone with a month or so to implement it.
-- 
David Roundy
http://www.darcs.net