Cloning locally a repo with subrepos using ../ in .hgsub
raphael.sebbe at gmail.com
Sun Jan 30 08:23:43 CST 2011
I'll second that, having sub-repositories at the same filesystem level than
the repository referencing them is definitely something that should be
possible, both on the client & the server (if we can say that).
Currently, we use symlinks in the client main repo to reference
sub-repositories one level above.
[I just moved to 1.7.3, did not retest that lately, but this was at least a
limitation in the pre-1.5 days]
Thank you for considering this,
On Fri, Jan 28, 2011 at 4:23 PM, Mike Williams <obsd1 at eandem.co.uk> wrote:
> I am investigating the use of sub-repos to share different subsets of a
> collection of libraries amongst many projects. This approach has been
> mentioned in other mailings to this list so I don't believe it is an oddball
> So, I have created repos of the libraries at the same level as the projects
> on the server, and then in each project reference the sub-repos for the
> libraries in the .hgsub files as:
> libname = ../libname
> As expected this is all working fine when for creating clones from the
> server. The pain has started with creating local clones from the clone
> created from the server - the relative paths no longer hold on the local
> machine. The aim is to follow the typical hg workflow of having a clean
> clones to exchange changesets with the master repos, and local clones to
> work on.
> Adding the subpaths extension and with a minimal .hg/subpaths file
> ../(.*) = \1
> I can then clone locally from the master repo clone and everything looks
> good until I want to interact with the master repos from the original clone.
> The simple solution is to rename/move .hg/subpaths somewhere else for the
> duration of the interactions and then move it back when working locally.
> There are two issues here I would like suggestions about:
> 1) Is there a better parent/sub-repo structure to represent this many
> projects/many libraries structure on the server? We have 10s of projects
> and 100s of libraries with no reasonable project to "own" a set of the
> libraries such that the normally recommended .hgsub entry of libname =
> libname becomes usable.
> 2) There does seem to be an idiom here to convert a server's flat sub-repo
> structure to a hierarchy locally. Should this be rolled into mercurial of
> the subpath extension, possibly just to remove leading ../ from .hgsub
> entries? This would be global command option (--internal?) so it doesn't
> change any existing behaviour.
> Yes there is a downside with this in that no one is reproducing the repo
> structure of the server, which makes rebuilding it after an outage an
> interesting activity in its own right - perhaps a server repo with all the
> repos being served as sub-repos of it. But this is disappearing up another
> line of thought so I will stop now.
> (*) A little bit of experience from experimenting with the subpaths
> extension. The subpath is (currently) as it appears in .hgsub and not
> normalised in anyway. If you have mixture of Windows and unix path
> separators present then you will need an entry of:
> ..(\\|/)(.*) = \2
> Mercurial mailing list
> Mercurial at selenic.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial