Subrepos and multiple top repos

[Mathias De Maré]

Hello,

I'm trying to tackle an issue related to subrepositories.

My setup is as follows (or will be, but I'm unsure about the best way to
proceed):

There are multiple top repositories (projects), containing a number of
overlapping subrepositories.
For example:
A contains subrepositories W, X and Y.
B contains subrepositories W, Y and Z.

I want to set up a central server, containing all of the repositories.
Preferably, I want to store all the repositories just once. Not out of space
concern, but to avoid multiple instances of repositories drifting apart too
much.
Also, I want people to be able to pull from and push to each other. So no
.hgsub with absolute links to the central server, but relative links.

I currently see the following options:
- store all the repositories in the same top-level directory, and put
symlinks in the top repositories to the subrepositories
- patch the server to always return a top-level directory, even when clients
request a subrepository down a few levels

Both of these seem quite annoying.
- The first requires adding new symlinks whenever a new subrepository is
added (or moved from one directory to another!).
- The second requires maintenance every time the server needs upgrading.

Is there another alternative?

One thing that seemed like an interesting idea is to expand .hgsub to a new
format:
directory = firstdirectory;seconddirectory

Suppose A has a subrepository W in directory foo/bar, and on the central,
it's stored in the same directory as A.
Then .hgsub could be:
foo/bar/W = foo/bar/W;../W

A client would first request foo/bar/W (which would fail), and then request
../W.
The client would then place the subrepository in foo/bar/W locally (since
that's the first option).

If another client pulls from the first client, it should work fine as well
(he pulls from foo/bar/W).

Are any other alternatives possible?
Yes, I know: trivial mappings are preferred. However, I'm not sure how we
should do trivial mappings in this case.

Greetings,
Mathias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110601/65d57504/attachment.htm>