Use SVN for project version management

1. Summary

This article describes how to use SVN to manage project versions, methods and principles involving project version naming rules, SVN directory structure, management of Third-Party code libraries, version creation, release, revision, and merging.

 

2. Version naming rules

The version number consists of the main version number, minor version number, and revision number. Major version changes: the primary version number increases by 1, and the minor version number and revision number return to zero. The major version number remains unchanged, the minor version number increases by 1, and the revision number returns to zero. When a bug occurs after a version is released, the major and minor version numbers remain unchanged, and the revision number increases by 1.

Note: The major or minor version number should be added for changes to the functional features of the active program, which should not be reflected by the revision number. A revision number is only used to revise bugs in a released version. The size of a revision number reflects the stability of a released version.

 

3. SVN directory structure

Project Structure

 

Third-party library structure

 

Use the project name as the svn repository name to create an independent project repository for the project. The main warehouse structures include branches and tags. Branches is the working directory, and tags is the publishing directory. The third-party libraries used by the project come out of the Independent Component Project warehouse, which is shared by all the projects of the company. The warehouse name is vendor.

 

3.1 project structure

 

Branches

Branch to store the unpublished version. A specific version is stored in a folder named after the "RB-version" rule. The example shows two versions of RB-2.0 and rb3.0 that are currently being developed. The Branch is the working directory of developers, the intermediate result of version implementation, and is temporary. After the version is released, the corresponding branch can be destroyed.

 

Tags

Tag to store the released version. A specific version is stored in a folder named after the "rel-version" rule. The example shows that there are currently two published version REL-1.0 and REL-1.1. This directory is read-only and cannot be modified on any released version.

 

Version Internal Structure

DOC: Document storage directory

SRC: directory for storing source code

Bin: executable files, dynamic libraries, scripts, configuration files, and other release items, as well as PDB, mapfile, and OBJ storage directories.

 

Vendor

Save the change log file change.xls of the third database. Because third-party libraries do not change frequently and the libraries are large, if they are stored together with the project code, the amount of checked-out code is too large and takes a long time. Therefore, only one change record file is stored in the project. The sequence structure is shown in the following table.

Database Name	Library version	Project version	Date of change	Remarks
Ace	4.5	1.0	2010-1-1
Boost	1.39	1.0	2010-1-1
Xerces	2.6	1.0	2010-1-1
Xerces	2.8	3.0	2011-12-29

The first row in the table above indicates that the xerces library was upgraded from 4th to 3.0 at project 2.6..

 

3.2 third-party library structure

A third-party repository sets up a separate SVN repository. Its location level is upgraded to the same level as that of each project, which is shared by various projects in the company. For details about its structure, see.

 

4. Common Operations

 

4.1 New Version

To create a version, create a version branch under branches to manage configuration items during version implementation. You can create a branch either from scratch or based on the published version in tags. For example, to develop 2.0 based on a REL-1.1, create a REL-1.1 from tags \ RB-2.0.

 

4.2 daily work

When assigning tasks to developers, the project manager must specify the version number, that is, the version of the task. Developers can implement and submit work results in the corresponding work branch based on the task version. In this way, developers only need to know the version number of the task and do not need to care about the relationship between versions. The project manager must have a clear understanding and planning of the version and Its Relationship.

 

Version 4.3 released

When a version enters the pending release status, you need to create a release tag for the version, that is, create a version tag from the version branch. For example, 2.0, A tags \ RB-2.0 is created from branches \ REL-2.0. The version publisher must obtain the release item from the tags to publish, so that the publisher cannot obtain the release item from the branch or other places for publishing.

 

Version 4.4 Revision

When a bug occurs in a released version, you need to create a branch version from the corresponding released version. For example, if a bug occurs after the 2.0 release, a branches \ REL-2.0 is created from tags \ RB-2.0.1. Note: The revision number must be added, and the version cannot be rolled back or changed in situ. That is, the version number must be added as long as it is a new feature or bug revision. After you enter the release status with a revised version, the version release process is displayed.

 

Merge version 4.5

When multiple versions are working in parallel, such as RB-1.0.1 (fixing bugs after 1.0 Release) and RB-1.1 (new features added after 1.0 Release, the RB-1.0.1 is completed and published prior to the RB-1.1, then the RB-1.0.1 is created after the REL-1.0.1 is published, and the changes to the REL-1.0.1 need to be consolidated into the RB-1.1, otherwise, a bug that has been modified in version 1.0.1 will reappear in version 1.1.

Use SVN for project version management