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).<div>
<br></div><div>Currently, we use symlinks in the client main repo to reference sub-repositories one level above.</div><div><br></div><div>[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]</div>
<div><br></div><div>Thank you for considering this,</div><div><br></div><div>Raphael</div><div><br><div class="gmail_quote">On Fri, Jan 28, 2011 at 4:23 PM, Mike Williams <span dir="ltr"><<a href="mailto:obsd1@eandem.co.uk">obsd1@eandem.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi<br>
<br>
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 requirement.<br>
<br>
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:<br>
<br>
libname = ../libname<br>
<br>
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.<br>
<br>
Adding the subpaths extension and with a minimal .hg/subpaths file containing(*)<br>
<br>
[subpaths]<br>
../(.*) = \1<br>
<br>
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.<br>
<br>
There are two issues here I would like suggestions about:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
TTFN<br>
<br>
(*) 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:<br>
<br>
..(\\|/)(.*) = \2<br><font color="#888888">
<br>
-- <br>
Mike<br>
_______________________________________________<br>
Mercurial mailing list<br>
<a href="mailto:Mercurial@selenic.com" target="_blank">Mercurial@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial" target="_blank">http://selenic.com/mailman/listinfo/mercurial</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Raphael Sebbe<br>
</div>