"sub repository" or svn:externals equivalents

[Steve Dyer]

Hi, I have used a feature in the past with SVN which allowed me to in
effect relate two codebases together, whilst at the same time keeping
them separate, and that was through svn:external. My deployed codebase
for example has a single root folder, in this case "app", and then under
that are 4 components, like this:



X:\live\app\ensura

X:\live\app\pcu

X:\live\app\pcw

X:\live\app\pin

X:\live\logs\..

X:\live\scripts\..

X:\live\files\...\..





Now traditionally I would store the entire "live" folder and all of the
sub areas within my SMC repo, as I want to have the full live deployment
contained therein. Obviously within things like the "logs" folder I
don't store away any files in the SCM, its really just the folder
structure for some of these that I am storing. The scripts contains all
the key configuration files required for example, so in that case the
folder and contents is getting stored away in the SCM. However the pcu,
pcw and pin directories, whilst they do contain masses of actual source
code required to run the application, this code is part of a secondary
framework, that generally is not under a change program. We have the
code so that we can change it, but realistically it is pretty static.
The main focus for our teams is the "ensura" folder.



In the interests of trying to trim down the day to day repository of
change, I was thinking of somehow hiving off the static elements of the
codebase, i.e. everything except the ensura folder. But at the same
time I want the whole collection under SCM somewhere. If I'm
remembering right, and it has been a few years now, in SVN I could have
the different elements in different repositories, but linked together so
that if I were to checkout the top level element, for example when
building a deployment, it would pull down all the related projects too
to give me the complete story. Equally in day to day operation, I could
just be working with the core element i.e. ensura without needing to
drag it all down.



Is this achievable in Mercurial, or am I best just throwing it all in
there?



Thanks





Steven Dyer
Design Authority (Europe & New Business)

HomeServe

[phone]
[phone]
http://www.homeserve.com <http://www.homeserve.com>

[Dennis Brakhane]

Take a look at http://mercurial.selenic.com/wiki/Subrepository

[Martin Geisler]

However the pcu, pcw and pin directories, whilst they do contain
masses of actual source code required to run the application, this
code is part of a secondary framework, that generally is not under a
change program. [...]

This makes it sounds like the pcu, pcw, and pin folders could be
subrepositories. Please see below.

In the interests of trying to trim down the day to day repository of
change, I was thinking of somehow hiving off the static elements of
the codebase, i.e. everything except the ensura folder. But at the
same time I want the whole collection under SCM somewhere. If I'm
remembering right, and it has been a few years now, in SVN I could
have the different elements in different repositories, but linked
together so that if I were to checkout the top level element, for
example when building a deployment, it would pull down all the related
projects too to give me the complete story. Equally in day to day
operation, I could just be working with the core element i.e. ensura
without needing to drag it all down.

Mercurial has a feature called subrepositories which does something
related, yet different, from what SVN does with its svn:externals.
Subrepositories lets one repository reference another, so if you
checkout "super", you also get "super/sub", with "sub" nested inside the
"super" repo.

However, you always get a specific revision of "sub", namely the
revision that was checked out when you last did a commit in "super".
This lets you use subrepositories for things like a build repository
where you know you need

build/
app/ <- some version of your application
lib-foo <- version 1.2
lib-bar <- version 3.4

When you checkout "build", you get a consistent snapshot. You can then
try updating the libraries and compile and test. If it works, you commit
in "build" to make a new snapshot:

build/
app/ <- some version of your application
lib-foo <- version 1.3
lib-bar <- version 3.4

SVN externals can also be used like this if you peg the external to a
certain revision. But if you don't peg it, then you get the latest
version of the externals when you update, and Mercurial subrepos are not
designed to handle this case. A build system should be used instead.

Subrepositories are a somewhat advanced feature and there are certain
caveats when using them, described here:

http://mercurial.selenic.com/wiki/Subrepository

My company made this guide which you might find useful to quickly see
how working with subrepos looks like:

http://mercurial.aragost.com/kick-start/en/subrepositories/