Using Subversion in big projects
Requirements on the Subversion setup
- It shall support an integration phase, where selected sub components are merged into one result.
- The sub components shall be possible to develop independently on the main application.
- The merged result shall be saved henceforth.
- It shall be possible to take a selected merged result and afterwards find out what it was integrated from; what the versions of the sub components are.
- All users of the application shall automatically get the same versions of the cub components, without having to do anything.
Suggested folder structure
This example project consists of one or more applications, where each one uses the sub components in Modules. Notice that the sub components in Module each have the usual branches, tags and trunk folders. The idea is that a release of a sub component is defined using a tag, or R1 in this example. Main projects should only refer to to the tags R1, etc, not to the trunk of a sub component.
If this project would have been check out from the BigProject level, each application would be able to refer to the sub components in the Modules using relative paths. However, the reference would depend on the tag names (R1, etc). Every time we would want to use a new release of a sub component, the source code in the main application would have to be changed so as to refer to the new tag.
Instead, a checkout of Application1 shall be done from trunk. Let's say it is called Application1. This folder will then have the property "svn:externals" added. This external definition will add one or more sub components from the Modules folder as a sub folder to the checked out project (Application1). The folder structure will thus look as follows. Notice that Core and Module1 look like they are part of the Application1 project.
^/BigProject/Core/tags/R1@28 Core
^/BigProject/Module1/tags/R1@28 Module1
- Always use version number reference for externals, using peg revision format. That is, suffix the source path with "@" and the revision number. Otherwise, if a module is renamed or moved elsewhere, it can no longer be referenced. This is needed even if it is a reference to a tags item.
- The externals can be in the same repository or another one. If it is in the same repository, use the relative repository path address "^/Module1/tags/R1" for example.
