SVN Source Code Management specification

1. SVN repository structure build

Subversion, in the eyes of most people, is the thing that is called "Trunk" in the code. In fact, subversion contains more content! To give you a better understanding of the benefits of subversion, this article will discuss how to build your repository structure. As you saw in the related articles of subversion, the most basic structure of subversion consists of three paths: Branches,tag and trunks.

Each path can be checked out separately in subversion.

1.1 Trunk

At any time the trunk contains the latest development code. The code here will work to your next major release.

As far as I can see, almost always people use trunks only to store their code. After releasing a version, continue with the next version of development on it. It's not good, either for you or for your product.

Trunks should only be used to develop code that will be the next important version of you. Do not add a version number and a publication name to the trunk. It is only necessary to ensure that the trunk is in "development mode" at all times.

Example:

Https://svn.example.com/svnroot/project/trunk

1.2 Branches

There are several different types of branches here. Here I will show you some common types. In the branches directory, you can create paths for more specific targets, like upcoming releases. As discussed in my article "article on releasing software from Subversion", the brahches path contains a copy of the trunk at different stages of development.

1.2.1 Release Branches

We've seen the rb-x.x release branches. When the trunk reaches the stage of preparation for release (or if you want to freeze the addition of new features), you should create a release branches. Release branches is just a copy of your current trunk.

This branches can be checked out separately you can also start branches and projects based on this version. You can also use this branch to fix bugs during testing. This approach ensures that the trunk continues to develop without being disturbed by the release of a specific version. So when you are ready to release a new version, this will not affect your trunk by adding new features.

1.2.2 Bug Fix Branches

Branches can also be used to handle serious bugs found in trunk or release branches. These bugs are complicated and you can't fix them at one commit. So in order to focus on correcting this error, you should create a new branch for this issue. This will not affect the continuation of the trunk and release branches, and you will not be able to interfere with the bug's fix by discovering new bugs and tests.

The naming of bug fix branches usually follows the following: The ID assigned to this bug using your defect management system. Usually this is a number. such as: Bug-3391.

Of course, you can also access your bug branch like any other branch.

1.2.3 Experimental Branches

Sometimes you want to introduce a new technology into a project. That's good, but of course you don't want to gamble on your entire project. Imagine that you want to change your Web program from PHP4 to PHP5. How long will it take you? During this time your trunk stopped using? Until you've done all the conversion to PHP5!

This is an experiment, maybe PHP5 is just as far from your program as the other end of the rainbow, and you should create a branch for him. You can make changes in the branch, and if you fail, you still have PHP4 code in the current branch.

If it fails, the experimental branch can be discarded. If successful, you can easily merge it into the trunk and continue with your new technology. The experimental branch name follows the polygon principle: prefix its name with "try-".

1.3 Tags

The tag backs up your code just like a branch. But tag is not used for development, they are just used to mark the state of your code.

1.3.1 Release Tags

Release tags tags the code for your release point. Release Tag is always a copy of the corresponding publishing branch. Release tag naming rule: "rel-" prefix plus version number.

1.3.2 Bug fix PRE and POST tags

When you create a bug fix branch, you want to mark the status of the code before and after Bugfix. This makes it easy to reference your changes and merge them into trunk or release branches.

Naming rules: "Pre-" plus bug ID;

"Post-" plus the bug ID.

2. SVN Usage Specification

Update first, then submit

The principle of SVN update is to be updated and submitted at any time. When a small function is completed, it can be submitted carefully after compiling and testing itself.

If someone changes the SVN file during the modification, the commit may fail. If others and themselves change the same file, then the update will be automatically merged, if you modify the same row, then the merger will create a conflict, this situation needs to contact with the previous developer, two people to resolve the conflict together, after resolving the conflict, two people need to test together to ensure that the conflict resolved, The program does not affect other features.

Note the list of updated files when updating, and if an update is generated during the submission process, it is also necessary to recompile and complete some of your own necessary tests before committing. This will allow you to understand what files others have modified, and also avoid SVN merge errors that lead to code mistakes.

Multiple submissions
Each commit interval is as short as possible, with a few hours of development work advisable. For example, when changing the UI interface, it can be submitted once for each UI modification or design. In the development of the function module, you can complete a small details of the function of the test, submitted once, in the modification of the bug, each modified a bug and confirmed that the bug was modified, also submitted once. We advocate multiple submissions, and we can add more insurance to the code.

Do not submit code that cannot be compiled

Before committing the code, you must first confirm that you are able to compile locally. If you use a third-party class library in your code, consider that some members of the project group may not have the appropriate third-party class library installed. When the project manager prepares the project workspace, it is necessary to ensure that the development team members are able to compile in a unified environment after the code is checked out.

Clear annotations must be written for each submission

Using SVN in a project group, if you submit an empty callout or an inaccurate callout will make the other members of the team feel helpless, the project manager can not clearly grasp the progress of the work, unable to clearly grasp the submission of the summary information. It is not possible to locate the file that caused the error correctly after the error is found. Therefore, when submitting a job, to fill in the clear annotations, can outline the information submitted to the file, so that the other members of the project team can see the label without a detailed look at the code to understand the changes you made.

Be careful not to submit locally generated files when committing

For example, the. classpath file in Eclipse, the windows generated thumbnail thumbs.db, the project compiles a temporary file generated by the. obj,. class, and so on. If this is not configured in the project to forcibly prohibit the submission of such a file, please do not submit such a file consciously. After submitting such a document, others may conflict with the local environment in order to affect the work of the people after the update.

Do not submit code that you do not understand

After the code is submitted to SVN, your code will be shared by the project's members. If you do not understand the submission of code, you do not understand, others can not understand, if in the future problems will become the project quality of the hidden danger. So before you introduce any third-party code, make sure you have a clear understanding of the code.

Use lock function with caution
In the project, you should use the locking feature carefully, after you lock a file, others will not be able to continue to modify the submission of the file, although you can reduce the incidence of conflicts, but may affect the work of other people in the project team. Usually only when editing the files that cannot be merged (such as file, flash files, etc.), the appropriate locking operation.

SVN Source Code Management specification