"sub repository" or svn:externals equivalents

[Martin Geisler]

"Steve Dyer" <Steve.Dyer at homeserve.com> writes:

> 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/

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/