[darcs-users] Implementation ideas for the "subrepo" concept.

[Michael Conrad]

First, I'd like to mention that I think that sometimes people want to make
collections of repositories (like I currently do) and other times they want
to take a large unified project and divide it into parts that can be worked
on semi-independantly.  For the former, I think the "subrepo" idea is
perfect, and for the latter I think there ought to be some kind of
repo-splitting system which I don't want to worry about in this thread.

The idea, as David stated it, was
> addsubrepo ./foorepo
> rmrepo ./foorepo
> subrepoversion ./foorepo [CONTEXT]
which is almost exactly what I want.  I currently have a large collection of
personal projects which I have grouped into categories and filed into a
giant directory tree.  I keep all the most current copies on my desktop
system, and then pull them onto my laptop as needed.  However, it is
annoying to remember which projects are named what, and so I basically want
a way to keep track of them.

With CVS, I was able to toss the whole wad into a giant archive tree, since
I could check out whatever subtree I needed.  With Darcs, it matters where
the "roots" are, and so if there are two mini-projects that will probably
never need to share files, I give them each their own repo.  However, I have
the "keep track of the projects" problem again.  It would also be nice to
track which projects have been updated compared to a mirror of my tree.
(i.e. for backups)

The user interface I want is something like the FreeBSD ports collection: I
want to be able to refresh the whole tree, and then change into a subdir and
pull the latest changes (like "make install").

This process can almost already be accomplished with darcs: I first create a
repo, add subdirectories to my heart's content, then run "darcs init" on a
leaf, and add the _darcs directory tree to the parent repo.

$ mkdir SubProject
$ cd SubProject
$ darcs init
$ cat "http://the.url.for/this/project" > _darcs/prefs/defaultrepo
$ cp _darcs/prefs/defaultrepo _darcs/prefs/lastrepo
$ cd ..
$ darcs add --boring -r SubProject
$ darcs record -a -m "Added sub-project SubProject" SubProject
# last line required because I don't want to capture any future changes to
SubProject

And ta-da, I can go to another machine and
$ darcs get maintree
$ cd maintree/path/SubProject
$ darcs pull

The problem is of course that as I work in SubProject, all the _darcs files
show up in maintree as changes, which I don't want to record.  (because of
things like recording changes to the "inventory" file, and checking that out
on a new machine, etc.)

So, I propose that darcs could automate the process as follows:

$ mkdir SubProject
$ darcs add --subrepo SubProject
Darcs: What is the default URL for SubProject? :
http://my.favorite.url/for/SubProject

Darcs now runs "darcs initialize on the directory, copies the url into
defaultrepo and lastrepo, and generates "addsubrepo ./path/SubProject
http://my.favorite.url/for/SubProject".
If the _darcs directory already existed, darcs could read the "lastrepo"
pref and use that as the default for the prompt.

So, now when I pull this on another machine, the patch "addrepo" ought to
cause creation of the directory and an "init" followed by copying the
default url into the defaultrepo and lastrepo files.  Conflicts would
operate on the principle that "There should be a repo here", so if that
directory already exists and has a _darcs directory in it, there's no
problem.

As for versions, I would think that there could be the concept of a "desired
tag", or "desired context" rather than "making the context so".  In other
words, darcs wouldn't take any action to make the subrepo match any specific
context- it would just start complaining about it until you go to that
subrepo and pull the right version.  I don't have any specific ideas about
when it would "complain", but maybe at the start of each record command in
the parent repo, or something: "Warning: sub-repo Foo does not match desired
context."

So, in summary, doing standard version control on the darcs files in a
subrepo almost works, but has issues that would go away if darcs had the
subrepo concept built in.

-Mike