Treat nested repositories as primary one (without using special commands)

[Kurt Granroth]

Hi all,

This is my first post to this list.  If all goes well, you'll be seeing
a lot more from me :-)

I'm evaluating using hg to replace CVS + darcs at work.  Specifically,
we're a full-blown CVS shop and are trying to migrate from that into
something a bit more programmer friendly and modern.  There are far too
many requirements to such a transition to detail here... but the main
general one is that we have to transition step-by-step.  That means that
CVS and whatever we choose must co-exist for possibly an extended amount
of time.  My research now is to try and find if Mercurial could do this
for us.

We're already well into our test using 'darcs'.  I'll have to say that
so far, we're loving it... but at the same time, we're running into some
serious drawbacks that are impeding wholesale adoption.  That means that
hg will have to be at least as good as darcs, sans the drawbacks.

Okay, that was a long-winded segue (warning: the rest of this post is
long-winded as well) into my first task: Find out if hg can work with
our existing project structure.  That is, can we get hg to treat nested
repositories as one big one... without having the end user use special
commands (read: probably not using 'forest').

We start with our base CVS modules:

lib
project/lib
dep
common-toplevel

We then combine them using the 'modules' admin file:

proj common-toplevel &lib &project/lib &dep

The fact that the modules are originally separate but are treated as one
big module is an absolute requirement.  This is because we share those
modules between quite a few projects.

We got this working with darcs.  Basically, we create a one-to-one CVS
to darcs mapping for each of the base modules (lib, project/lib, etc).
Then we create a "meta" repo that contains all of the individual repos
in stacked in the correct order.

meta-common-toplevel/_darcs
  lib/_darcs
  project
    lib/_darcs
  dep/_darcs

Then we do a big 'darcs add -r .' at the top-level.  That means that
that I can do a 'darcs pull meta-common-toplevel' as an end user
developer and it will pull the entire directory structure as if it was
one big repo.  This is critical that the end user have no real knowledge
which of the subdirs is really backed by an individual repo.

When it comes time to sync again, we just go through each of the nested
repos and do a 'darcs commit -l' there to get a repo-specific patch that
we can then push into the CVS backed repo.

This works pretty well.  Now how to do this with hg...

I tried just doing an 'hg clone' of all of the individual repos in the
right structure and doing an 'hg add' at the top-level.  That didn't
work.  It seems that hg notices the underlying .hg dirs and doesn't try
to add those files as new?  I guess that's handy in most cases, but it
effectively throws our darcs solution out of contention.

The 'forest' extension looks promising but it has the downside that it
keeps the individual repos around every time you clone.  So the end
users absolutely have to remember to use 'fpush' and 'fstatus' and the
like.  Plus, they have to do the 'commit' in the proper sub-repo, not at
the head.

Has anybody dealt with a situation like this?  Or will we have to do
some sort of scripting?  I'm thinking something like:

1. Create our 'master' meta repo with the correct nested repos
2. rsync over the master into a 'simplified' by EXCLUDING all .hg
directories
3. Do an 'hg init && hg add' in the 'simplified' as if it was a
brand-new repo
4. (Developers clone off the simplified to do their development)
Here's where it gets fuzzy
5. Use something like the darcs version of pull (one patch at a time)...
maybe transplant?  Get one changeset at a time
6. Copy over the changes into the 'master' repo
7. Go through each nested repo and do an 'hg commit' using the author
and description from the original changeset

That would probably work as long as we could cherry-pick the pulled patches.

I'd much rather have a more official way of doing it, though ;-)

Thoughts?
Kurt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://selenic.com/pipermail/mercurial/attachments/20071028/0752e582/attachment.pgp