SVN → Connecting external libraries

So, today we will talk about connecting external libraries (sub-projects) to main projects using Subversion .
According to the good old tradition, TortoiseSVN , long beloved by us, will be used as a client for working with SVN .

As usual, everything described below does not claim to be an innovative idea. This is just an exchange of experience, the purpose of which is to facilitate the work for developers.

Connecting external libraries can be a very useful "trick" of the version control system, especially when you are working on several projects that use the same library (this can be anything from a class for working with databases to system templates).

For example, let's define the source data:
we have two projects (“One”, “Two”) and one library (“Library”), which need to be implemented in both projects. Let we have the following way to this library: subserver/code/library/trunk subserver/code/library/trunk .
We have working copies of both projects. Suppose that in each of them there is a folder /libraries/ , inside of which we need to create a folder /library/ , in which our external library will be located.
I initially point out that the library will be in a separate folder, since The svn:externals property, which we will use, works only with folders.
')
Further, everything turns out to be very simple: open the properties of the /libraries/ folder of any of the projects ( two projects are described solely in order to show how the update works ). It will look something like this:



Click the Add... button, and we see a window for adding properties, something like this:



In the drop-down list, select the item svn:externals (the first in the list). Next we need to write the value of the property. For svn:externals value is the following line:
- -- , where for our example the folder name will be: library , and the path to the repository will be: subserver/code/library/trunk subserver/code/library/trunk .
Literally, our line will look like this:

library subserver / code / library / trunk

The path to the repository can be easily obtained using the Repo-browser utility included in the TortoiseSVN package.
The delimiter can be one or more space or tab characters. Personally, I use four spaces.

It should be mentioned that it is possible to specify a specific revision for the library, but in most cases this is an undesirable action, since we will not be able to make any changes to the library.

Actually, on this all innovations end. We save properties.
Next, we need to do Update to make sure that everything is correct and the library is successfully loaded into the project. This will create the /library/ folder automatically. If everything is smooth, we do Commit to save the folder properties directly to the project repository. From now on, in all working copies of this project (i.e., all developers), the necessary library will be connected automatically.

Now we are doing completely similar actions with the second project (folder names may be different, but this is not important). As a result, we get two projects using the same external library.

Now let us assume a situation where when working on the project “Two” we need to change something in the library. We make these changes directly to files that are physically located in the /libraries/library/ folder. After all changes have been made, we commit. And the changes are automatically entered into the library repository: subserver/code/library/trunk subserver/code/library/trunk . If you now make the Update project “One”, there will be downloaded an updated version of the library.
There is a subtle point about the comments added to the Commit: if the changes concern both the project and the library, then all comments will be recorded in the logs for both the project and the library. So I recommend saving these changes as separate revisions.

Another potential danger that inexperienced programmers may face is the incompatibility of the new version of the library with some of the projects. There are two answers to this: 1. write compatible code so that it works everywhere. 2. You can use branches (branch) to separate the previous version of the library, and connect it to the project (in a completely similar way).

And finally, practically quotation from the documentation: remember that svn:externals are folder properties, so if your project or external library is moved somewhere (for example, by Relocate), the paths in the properties will not change automatically, will need to be fixed manually.

That, in general, is all that I wanted to tell you today.
As always, I enjoy reading your comments.