Mercurial: how to see the forest behind the trees?
Mercurial (aka Hg ) is a very nice distributed version control system (distributed VCS). Among the amenities of DVCS in general and Hg in particular, high flexibility can be highlighted. The repository can be called whatever you like, copied anywhere, committed to production by arbitrary chains (say, through QA or directly) and so on.
Well, even repositories can be nested. For example, your project consists of several smaller ones or includes third-party products. It is more convenient for module developers to work not with the whole project, but with its parts. In these cases, you can combine repositories.
If two repositories are embedded in one another, Mercurial will consider them in isolation. Commands addressed to an external repository do not apply to a sub repository. But how to manage a project if it is fragmented into isolated fragments - sort of bubbles, one in the other? Or, in other words, how do we see the forest (project) behind the trees (repositories) and work at its level? ForestExtension , an extension for Mercurial, will save us from torment . This Forest adds several commands that are identical to the basic ones, but take into account the nesting of repositories.
Let's say we took a large composite project to our home, corrected the files in all the modules, and we want to push them back. The team
Let's create two repositories, each with a text file: Copy the first repository inside the second: Do not forget that repo-two / one is not part of repo-two , it is simply nested there. And now Forest comes onto the scene. Command
We just made a local copy of repo-two , including repo-two / one (copy of repo-one ).
We’ll make some changes to repo-two / hello.txt and repo-two / one / hello.txt (omit the listing).
Commit the changes in each of the repositories separately (it is easy to guess why there is no “forest” analogue of the command
The next step may be to push the changes further, i.e. in repo-one : Done; now the changes from repo-two / one passed to repo-one . That's all. Instead of repo-two / one there can be a whole set of trees, and will process them all. (the original topic is sitting here: http://neithere.livejournal.com/381205.html )
Well, even repositories can be nested. For example, your project consists of several smaller ones or includes third-party products. It is more convenient for module developers to work not with the whole project, but with its parts. In these cases, you can combine repositories.
If two repositories are embedded in one another, Mercurial will consider them in isolation. Commands addressed to an external repository do not apply to a sub repository. But how to manage a project if it is fragmented into isolated fragments - sort of bubbles, one in the other? Or, in other words, how do we see the forest (project) behind the trees (repositories) and work at its level? ForestExtension , an extension for Mercurial, will save us from torment . This Forest adds several commands that are identical to the basic ones, but take into account the nesting of repositories.
Let's say we took a large composite project to our home, corrected the files in all the modules, and we want to push them back. The team
fclone
(forest clone) will copy us the “forest” of the nested repositories (ie the project), the teamfstatus
(forest status) will show the state of the entire “forest” (is it necessary to commit something?), and fpush
(forest push) will push all changed files back, and will do this for the entire “forest” at once, i.e. we don’t have to crawl through catalogs. In this case, the “back” is to the original, public “forest” of the project. If you also want to push changes from there to some third-party repositories, it is enough to repeat the same within the framework of the project fpush
- and you're done. Let's create two repositories, each with a text file: Copy the first repository inside the second: Do not forget that repo-two / one is not part of repo-two , it is simply nested there. And now Forest comes onto the scene. Command
$ mkdir repo-one
$ cd repo-one
$ hg init
$ echo "hello" > hello.txt
$ hg ci -m"init one"
$ cd ..
$ mkdir repo-two
$ cd repo-two
$ hg init
$ echo "hello" > hello.txt
$ hg ci -m"init two"
$ cd ..
$ hg clone repo-one repo-two/one
fclone
similar to the clone command, but, unlike it, does not ignore nested repositories. $ hg fclone repo-two wc-two
We just made a local copy of repo-two , including repo-two / one (copy of repo-one ).
We’ll make some changes to repo-two / hello.txt and repo-two / one / hello.txt (omit the listing).
Commit the changes in each of the repositories separately (it is easy to guess why there is no “forest” analogue of the command
commit
):
Push the result back to repo-two :
That's it, now repo-two contains the modified files repo-two / hello.txt and repo-two /one/hello.txt .$ cd wc-two/ && ls
one hello.txt
$ hg ci -m"edited hello.txt"
$ cd one/
$ hg ci -m"edited hello.txt"
$ cd ..
$ hg fpush
The next step may be to push the changes further, i.e. in repo-one : Done; now the changes from repo-two / one passed to repo-one . That's all. Instead of repo-two / one there can be a whole set of trees, and will process them all. (the original topic is sitting here: http://neithere.livejournal.com/381205.html )
$ cd ../repo-two
$ hg fpush
fpush