Subrepos and multiple top repos

[Martin Geisler]

Mathias De Maré <mathias.demare at gmail.com> writes:

> 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!).

You'll need to log into the server anyway in this case: you cannot
create new (sub)repositories on a server without a login.

Your options are:

* symlinks

* the share extension (sort of in-Mercurial symlinks between .hg folders)

* let hgweb export the same repository under several different paths

Those three ways will let clients clone subrepos using trivial subrepo
paths and there will only be one repo on the server.

> 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).

Yes, that is an interesting idea and I've even proposed in the past that
the trivial path is always used first with "real" path from .hgsub used
as a fallback in case the trivial path does not work. This was last
mentioned here in a greater context of using a local cache for a clone:

  http://mercurial.selenic.com/bts/issue2818

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20110601/a3269b51/attachment.pgp>