Mercurial for parallel work with several similar projects, part 1

Introduction

The article discusses several problems (and useful features) when working with mercurial and suggests solutions for them.

Several projects on one framework

Suppose we use some kind of framework in several projects at once. To do this, we, as a rule, clone the base repository and begin to change files in it related only to our project, test, commit, push - everything as usual.

Suddenly ... we find that there is a bug in the framework itself, or we simply don’t have the strength, we need to add some functionality, but at the same time test it with the current project.

At the same time, we understand that these changes should sooner or later get into the framework repository.



What to do?



The most obvious solution is to use patches. We wrote, checked, selected only the files related to the framework, made a patch, applied the patch to the project repository, committed and started where to, updated in other projects as needed.

')

And if you need to do it all the time?

Now let's imagine a situation where we are simultaneously working on several similar projects based on the same framework, or we are writing our own framework. We will create a separate repository for development, in which we will develop and test generalized parts for all projects. For example:



Local development repository :

• core - framework files
• shared - shared files for projects
• custom - files required for testing

And you will also have a repository-repository of generalized parts (or framework):

• core - framework files
• shared - shared files for projects

The custom folder in this repository is naturally absent, otherwise with any changes, they will fall into the repositories of individual projects, which is unacceptable.



Changes are distributed according to the following scheme:



development repository → repository repository → project repositories → (patches) development repository

How to organize this with a minimum of nerves?

Firstly, symlinks with mercurial will not work, and all options related to file sharing between working copies should be discarded. (hardlinks would work if they could be done on directories)



So we need to ignore the custom folder. In the mercurial repository, there are two main methods of "ignoring":

1. Using the .hgignore file in the repository root
2. Using .hg / hgrc ignore

The first method does not suit us, as .hgignore is placed in the repository and will ruin the life when developing individual projects.



But the second way - what you need:



1. Create a file similar to .hgignore, put it in a convenient place (for example, in the .hg folder or outside the repository).



2. In the [ui] section of the .hg / hgrc file, create the option:

ignore.whatever = <absolute path to the file with rules for ignoring>

(By the way, there are plenty of such options with different “whatever”)

Conclusion

Of course, it was possible to significantly reduce the text of the article, and limit the mention of the “second method of ignoring”, but this article is only an introduction for a more serious discussion about the development of such projects.



In principle, the described model is fully operational, but it also has significant drawbacks, which we will try to get rid of next time, and at the same time we will even learn how to write plugins for mercurial.