Mercurial‎ > ‎

Subreposetories in mercurail

Subreposetories in Mercurial

How do you organize and maintain subrepositories in Mercurial?
We would explain how to organize your repository layout in Mercurial for getting the most from subrepositories and how to implement it in real life and we will list the the draw backs/missing features of this.

Organize

1) First of, deciding how to layout your repository. this is pretty  easy. Say you have project A that depends on Lib A-1, this should be like.
 
Project A/
  utillities/
    Lib A-1  

2) We could also take a (maybe more realistick scenario) Project B depends on Lib B-1 which uses Lib B-2 and Project B also uses Lib A-1 this is bit more complex but easy to handle.

Project B/
  utillities/
    Lib B-1/
      utillities/
        Lib-2
    Lib A-1/

Doint it!

First of we need to talk about prestine copies(explained briefly), this is an easy way to save space on linux and a great way to only pull over the network once for changes. But this does not work well with subrepositories, if you ues prestine copies you should be aware of the you would, when you push to youre prestine copy, push youre project to prestine, but all subrepoes would be pushed to theire  central repos as specified in the .hgsub file. this is not a problem if the developers are aware of the issue and you have set up youre validation strategi right which we will cover later in this article.


To do this always start with the repository in the buttom of the tree, so if we take example 2 from before this would be to include Lib B-2 into Lib B-1 so changes dir into the root of Lib B-1. 

Implementing the subrepossitory structure
echo utillities\Lib B-2 = http://url/to/Lib B-2/repository > .hgsub
hg add .hgsub
hg clone http://url/to/Lib B-2/repository  'utillities\Lib B-2'

The this procedure is repeated for each subrepository there is in the top project strukture.


Validating strategies

You need more than one central repository. The first one you create is the integration repos, this repos is where all development will meet, every developer has the possibillity to branch of in different branchs to do different work, but they are not done until they deliver the changeset to the default branch, this is here the build server monitors for changes. and if the server finds new version it will pcik them up an build-and-test1 them. if every single test is succeeded it will push to a new central repository called 'release'  and then there is done a more complex test.

Drawbacks

Most of the commands in Mercurial takes a '-S' option that tells the command to execute recursive down into all subreposetories and this is quit effective, giving you the option to run one command on all youre repositories in the project.
Unfortunately this is not the case on the 'branch' command which is maybe the one command that you whis this would work on

If you have several subreposetories you should se this page

If you only have one subrepository would it be easier just to run the command 2 times.









1) does every single validation of the code, this is defined by the build process.




Comments