How we used SVN in a complex project

Start

About more than a year ago, a new project was launched at the enterprise, and which has now been completed. They commissioned me and my colleague to do it.

The Qt library was chosen as the basis for development. Since all the projects at the enterprise were conducted in Delphi before, we became pioneers of this powerful tool. Prior to that, none of us had been developing commercial products using the Qt library.

We chose version control system quickly - SVN. Because we already had some experience with it, and also because it was necessary to start somewhere. Strangely enough it sounds, until this point, our enterprise did not implement anything similar to the version control system (SLE), except for the archive on the server, in which each programmer had his own directory, and in which he was the owner.
')
Everything described below refers to the practical experience of using SVN in Qt projects with a mix of modern business realities.

Development of repository structure (storage)

After analyzing the work ahead, we quickly created all the main source folders in the repository (I will call each individual repository repository) on my machine, starting with the notorious trunk, branches, tags and ending with various specifics. Agreed on the naming of folders, files and style design code. The document on the style design of C ++ code in the enterprise has helped us a lot with this. All newcomers to the team got acquainted with this document before work and there were almost no questions in the future. Then we added users and started working.

Start of problems

After a month of development, we already had several repositories on the server. One major for the main project. There were two main programs with many common components. The rest were created for the created tools, large subsystems, which were supposed to be used in other projects.

And then there was the first problem. I created a simple repository on my machine and gave access to my colleague using VisualSVN. Before creating a separate storage on the server, hands did not reach that moment. Our administrators and management completely ignored the requests to organize a separate server with automatic backup for the centralized storage of not only our project, but all subsequent ones. For a while I coped with the administration of the repository, creating backups to a removable hard drive.

The fact is that I had to move to another room. And this is a change of ip-address. For the repository, this is not only the notorious relocate, but also the editing of all properties of folders containing svn: externals. This little nuisance was quickly defeated and work continued on. Storage is left in my car.

Verdict: It is necessary to organize a separate server for storage.

Further more

The second problem was the disagreement in the organization of the structure of the subproject repositories. For some subprojects, we also created a popular folder structure: trunk, tags, branches. Although trunk was always used in the build, and in all pro-files there was a very unattractive path containing trunk. It was decided to create a folder with all the necessary external inclusions for each of the two programs in this storage. In this folder were also created pro-files to build a common project. Taking into account the chosen model, one project is one repository, we have not experienced any negative consequences from such a decision in further development.

Verdict: If the approach is one project - one repository, then the folders trunk, tags, branches should be placed only in the repository root.

In the process of working on the project, 3 more programmers joined us at different times, all were beginners. Two developed a certain limited functionality - modules, libraries that rarely came into contact with anything, and one participated along with us in the development of the main system. They also like we made changes and new code in the repository. Also, over time, the requirements changed, in some areas significantly, so the structure of the repository changed slightly, the subprojects were transferred, the code was corrected.

And somewhere in 8 months from the beginning of development (we don’t have testing groups, that is why programmers are engaged in tests) when two programmers started working on the project again, we realized that we made another serious mistake. If you merged the contents of the repository, it was not possible to assemble anything without additional manipulations, and at the same time each programmer knew how to assemble only his own modules. The situation was aggravated by a large number of code, a large number of modules and their dependencies. The decision was on the surface.

First, we started to create different pro-files for the same modules, but with different compilation paths, and different locations of the final binary files. Secondly, all sub-modules began to be placed in the repository with their pro-files, if it is a library, or with pri-files, if it is just code that needs to be included somewhere. Now the main pro-file before assembling the main project collected all dependent libraries.

Secondly, we created in the root of the folder where the most important pro-files were the include and lib folders. In the include folder we began to place header files without an extension with one line of approximately the following content: #include “../modude1/src/modile1.h”. This allowed for the work to include only one directory with header files and not to worry where the necessary files are located. And in the lib folder were placed all the libraries collected from the subprojects. Thus, having registered only one directory on the way, we have excluded all dependencies on libraries.

Verdict: It is extremely important to maintain the principle: leaked from storage and collected without problems.

The idea of ​​creating a civilized repository for ours when it was brewing more and more towards the end of development. With one of the programmers, we found an idle machine. Debian, SVN, FTP was installed on it. Transferred all the storage on it. After a couple of months, the hard drive failed on my working machine, so the importance of backups and centralized archiving of the accumulated code cannot be denied.

Verdict: It is necessary not only to have a separate server for storing the code, but it is also important to set up its archiving.

For control of the archives and server health, after the initiator of the creation of the server has left, I have to answer.

In winter, my colleague, a basketball player, discovered volleyball and in the second week he tore ligaments on his leg. In general, the project is quite traumatic. Prior to this, the chief designer broke his leg. Another programmer was hit by a car, the benefit is not much - he went to work in a week. Already autumn - without incident! In general, our programmer was out of operation for three months, but continued to work at home.

This is the only time when we felt the lack of a distributed version control system. Upon return of a colleague, the code was successfully added to the repository by brute force, that is, by hand.

Verdict: You need to learn how to work with patches and do merges.

Almost end

And last week it was necessary to put the whole project together and then we had to sweat. Despite the fact that almost everything was already assembled according to the principle: merged the version and assembled, some parts (the most recent developments) had not yet been added to the repository. In some places there were incorrect configuration files or tests were not added to the repository.

Verdict: I started work on the task - put it first in the repository.

findings

The project is almost finished. We experienced a constant lack of information, changing requirements, machine failures and burning equipment, rapid development in a small team. Today, the preliminary acceptance was successful, everyone liked everything, the software worked without errors and failures, the state commission is ahead. The source repository is almost put in order. It can be seen that in this project we have filled ourselves with enough bumps on errors in working with SVN and henceforth, I hope, we will not repeat them. Successful team work in version control systems!