How to Use SVN to manage our source code

How to Use SVN to manage our source code

Today, I configured the SVN server of the company. According to different departments of the company, I divided different access directories and assigned corresponding permissions to different directories, I have finished this task, but I am not satisfied with my work and regret it because the configuration of the company's SVN server does not comply with the code management specifications, there are no branches and no labels. I always want to do things to the extreme. At least the top-level design should be reasonable to facilitate future users, but at present, I am not qualified to promote my idea as a company, Luo. I have to indulge myself in this article, imagining how to use SVN tools to make standard source code management.

1. SVN Overview

As the scale of the project grows, the method of modifying code by email is too slow, which seriously affects our work efficiency. In the future, we will use SVN to manage the development of the project.

The full name of SVN is Subversion. It is a version control system that can bring many benefits to the team when developing projects: it provides the team with a project-level revocation function, nothing is final, and errors can be easily rolled back. That is, any modifications made by team members can be undone.

It allows multiple programmers to write code for the same program in an orderly manner. The team will no longer lose the work it has done because someone has covered the edits made by other team members.

The version control system records changes every moment. If you encounter some modified code, it is very convenient to find out who wrote it. You can also use the log to find out why you want to write it like this.

The version control system allows you to release multiple versions at the same time while developing the main line. With the version control system, the team does not have to stop working before release to freeze the code.

The version control system is a project-level time machine that allows you to enter a date to see what the project looks like at that time.

Although SVN can help our team collaborate more effectively, if improperly used, it will not only bring us any convenience, but also reduce our work efficiency. Therefore, this specification is compiled, the purpose is to facilitate your work.

2. Directory Specification

The SVN directory structure of a regular project generally has three folders: 1. trunk, 2. branches, 3. tags, these directories are essential in a standardized project, taking into account both efficiency and code security. Next I will introduce their functions.

2.1 Trunk

At any time, Trunk contains the latest development code. The code here will work for your next major release version. As far as I can see, almost all people use trunk to store their code. After a version is issued, the development of the next version is continued. This is not good, whether it is for you or your product. Trunk should only be used for development and will become your next important version of code. Do not add the version number and release name to trunk. You only need to ensure that trunk is in the "development mode" at any time ". Example: https://svn.example.com/svnroot/project/trunk

2.2 Branches

There are several different types of branches. Here I will tell you some common types. In the branches directory, you can create more paths for specific targets, such as the forthcoming version. As discussed in my article "article on releasing software from Subversion", the brahches path contains copies of trunk in different stages of development.

2.2.1 Release Branches

We have seen the RB-x.x release branches. When the trunk reaches the release preparation stage (or you want to freeze the addition of new features), you should create a release branches. Release branches is only a copy of your current trunk. This branches can be checked out separately. You can also start projects of branches and later versions. You can also use this branch to fix bugs during testing. This method ensures that trunk continues development without being disturbed by the release of a specific version. Therefore, when you are about to release a new version, this will not affect your trunk to add new features.

2.2.2 Bug fix branches

The branch can also be used to handle serious bugs found in trunk or release branches. These bugs are complex and you cannot fix them at one commit. Therefore, to focus on correcting this error, you should create a new branch for this problem. This will not affect the continuation of trunk and release branches, and you will not interfere with the fixing of this Bug because of the discovery of new bugs and tests. The name of the Bug fix branch generally follows the following method: Use the ID assigned to this Bug by your defect management system. This is usually a number. For example, Bug-3391. Of course, you can also access your Bug branch like other branches.

2.2.3 Experimental branches

Sometimes you want to introduce a new technology into a project. This is good, but you certainly don't want to bet on your entire project. Imagine you want to change your Web application from PHP4 to PHP5. How long does it take you to spend? During this period, will your trunk be stopped? Until you have completed all the conversions to PHP5! This is an experiment. Maybe PHP5 is too far away from your program like the other end of the rainbow. You should create a branch for it. You can make changes in the branch. If it fails, you still have PHP4 code in the current branch. If it fails, the lab branch can be discarded. If it succeeds, you can easily merge it into trunk and continue with your new technology. The lab branch name follows the principle of adding the prefix "TRY-" to its name -".

2.3 Tags

The tag backs up your code like a branch. However, tags are not used for development. They are only used to mark the status of your code.

1.3.1 Release tags Release Tags

Code that marks your version release point. The Release Tag is always a copy of the corresponding Release branch. Release Tag naming rules: prefix "REL-" and 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 the BugFix. In this way, you can easily reference your changes and merge them to trunk or Release branches. Naming rules: "PRE-" and Bug ID; "POST-" and Bug ID.

3. SVN usage specifications

Update first, and then submit

The SVN update principle is to be updated at any time and submitted at any time. When a small feature is completed, it can be compiled and tested by itself, and then submitted with caution. If someone else changes the svn file during the modification, the commit may fail. If others change the same file, the file will be merged automatically during update. If the modified row is the same, a conflict will occur during the merge, in this case, you need to contact the previous developers and negotiate with them to resolve the conflict. After the conflict is resolved, You need to test together to ensure that the program will not affect other functions after the conflict is resolved.

Pay attention to the list of updated files during the update process. If an update is generated during the submission process, you also need to re-compile and complete some necessary tests before submitting. In this way, you can understand which files have been modified by others, and avoid code errors caused by SVN merge errors.

Multi-submit

The interval of each submission is as short as possible. It is best to work on development within several hours. For example, when you change the UI, you can submit the UI once every time you modify or design the UI. When developing a function module, you can submit each time you test a small-Detail function. When modifying a bug, you can modify a bug and confirm that the bug has been modified, it will be submitted once. We advocate multiple submissions, so we can add insurance for code.

Do not submit code that cannot be compiled

Before submitting the code, make sure that you can compile it locally. If the third-party class library is used in the code, consider that some members of the project team may not have installed the corresponding third-party class library. When preparing the project work area, the project manager must consider this situation to ensure that the development team members can compile the code in a unified environment after checking out the code.

Clear annotations must be written for each submission.

When SVN is used in a project group, if empty or inaccurate annotations are submitted, other members in the Project Group may feel helpless and the Project Manager cannot clearly grasp the work progress, the summary of this submission cannot be clearly grasped. After an error is found, you cannot accurately locate the file that causes the error. Therefore, when submitting a job, you must enter a clear description to briefly describe the information of the submitted file, let other members of the project team understand your modifications without looking at the code in detail after seeing the annotations.

Do not submit files automatically generated locally.

For example, the. classpath file in eclipse, the thumbnail Thumbs. db generated by Windows, the temporary file. obj and. class generated by project compilation, and so on. If this configuration is not configured in the project to forcibly prohibit the submission of such files, do not submit such files. After submitting such a file, someone else may conflict with the local environment after the update, thus affecting everyone's work. Do not submit code that you do not understand

After the code is submitted to SVN, your code will be shared by the project members. If you submit code that you do not understand, you cannot understand it, and others cannot understand it. If you encounter problems in the future, it will become a risk of project quality. Therefore, before introducing any third-party code, make sure you have a clear understanding of this Code.

Use the lock function with caution

Use the locked feature with caution in the project. After you lock a file, others cannot continue to modify it.

Submitting this document may reduce the conflict rate, but may affect the work of other personnel in the project team. Locking is applicable only when you edit files that cannot be merged (such as instance files and flash files.

4. General Operations

4.1 file Detection

After TortoiseSVN is installed, SVN will be perfectly integrated with the Windows Resource Manager. Right-click the file. On the menu bar, select the SVN check-out option and enter the URL of the file library to check the code. Then, we can check out the file in the file library under the URL. By default, the code of the latest version is checked out. If necessary, you can view the log to find the desired version based on the log, then, specify the corresponding version in the "version" option to check the relevant Code 1. Then, for the Backbone Development of the same project, we will operate in the directory of the detected code file, instead of checking every commit or update.

4.2 Add a file

Files (including directories) created locally are not controlled by SVN. To allow them to accept SVN control, they must be added to the file library. For files required by other team members, such as code files and some modules. file a (because of some requirements, the code of this module is not public), we must make them accept SVN control and keep the latest version.

4.3 Delete a file

When you need to delete useless files (including directories), you must use the delete file function of SVN instead of Windows resource management tools. In this way, after the file is deleted, all its modification history will still be saved on the SVN server, and the modification history of the file will still be available in the future.

4.4 rename a file

To rename a file (including a directory), you must use the File rename function of SVN instead of Windows resource management tools. In this way, after the file is renamed, all the modification history before it is renamed will still be saved in the SVN server to maintain continuous modification information.

4.5 update

Changes submitted to SVN by other team members will not be automatically updated to your local copy. We need to update the file to get the modifications made by other Members to the project file. The SVN file update operation will merge the files in the file library with the local files, so as to retain the modifications of other members and local modifications at the same time. If Automatic merge fails, a conflict occurs. You must use the file comparison tool to manually merge the files before submitting the files that have already been resolved. For details about how to resolve a conflict, see Chapter 3-conflict resolution. During team development, updating is a very important task. It can ensure that the work content of team members is consistent. Therefore, you must update your work copy frequently, to ensure that you can get the latest modification content. 4.6 submit changes

All changes made to files (including directories), including adding, deleting, and modifying files, must be submitted to the SVN Server File library to take effect, then other members of the team can obtain your modifications.

Submission is an important operation that requires:

1) before submitting the code, make sure that the modified Code can be compiled and cannot be submitted. Compare the code before and after modification, remove the debugging information or other irrelevant information, and ensure that the submitted code is

Correct and the files to be submitted are submitted.

2) Don't wait until many code modifications are submitted. Instead, you should submit the code once when the related minor functions are completed. In this way, you will find that

It is easy to undo problematic code when a question occurs. Because Undo can only be performed once, too many functions are involved in a single submission.

3) You must enter the log information during submission, indicating what features or bugs have been added to the submission. This information helps

Understand the history of the entire project by yourself and other team members. When a problem occurs, you can easily locate the corresponding version code. Therefore, the log information must be detailed enough.

4) transaction commit. That is to say, the submission is either successful or all failed-that is, the system will automatically roll back when an error occurs in the submission.

I have not submitted anything. When an error occurs, resolve the error and submit all the content submitted last time.

Appendix: Guidelines for the use of SVN by the test automation team

1. Project Construction

The directory architecture of the Project on the SVN server is as follows:

Project files on SVN:

1. Ensure that the Code on Trunk is up-to-date! Code on Trunk is updated regularly.

Situation self-grasp

2. Tag is a Tag based on project requirements. Each released version requires a Tag, which is mainly used for convenience.

Directly return the status based on the Tag for analysis and testing. The Tag must contain the corresponding release file and the source code at the time of compilation or release, relevant documents must be provided to indicate the project background and release status.

3. The Branch folder can be used for backup and can be named by a personal name. In addition, the Branch is mainly used for backup.

For a short or exploratory development and use, the final software version must be updated and merged to the Trunk. 4. Suggestions on the development environment of the same project team: the development environment of members of the same project team should be the same, and the software installation path and

The best path for storing Project files is the same.

2. Version Number

Version naming rules: Major version number. Subversion number. Corrected version number

1. The first project version is 0.1.0;

2. When the project is partially modified or the bug is corrected, the main version number and the sub-version number remain unchanged. The corrected version number is added to 1;

3. When some functions are added to the project on the original basis, the main version number remains unchanged, the sub-version number is added with 1, and the version number is reset.

0;

4. When the project has accumulated a large number of major modifications or partial corrections, resulting in a global change of the project, the main version number

Add 1 and reset the sub-version number and the corrected version number to 0;

5. The compilation version number is generally automatically generated by the compiler during the compilation process. We only define the format.

Dynamically generated and manually added. The value indicates the current system time. Example: V1.0.1 Build090305 Rel111123 use rules for other versions: 1. Alpha (alphal) Internal Beta

This version indicates that the software is only a preliminary finished product and only communicates within the Group. This version has many bugs and is limited to internal testing.

Example: V0.1.1 Build090305 alphal1 2. beta external test

This version has been greatly improved compared with Alpha, and has been tested in the group to eliminate serious errors. However, there are still some defects that need to be further eliminated through large-scale tests. Example: V0.1.2 Build090305 beta1 3. demo

This document can only be used for review or explanation. Example: V0.1.3 Build090305 demo1 4. release final version

This version means the "final release version". After a series of test versions, there will eventually be a formal version. Generally, release will not appear on the software cover in the form of words, replace it with the sign (Rel ). When releasing a release version, you must package the software to be released and the corresponding version update records. Example: V1.0.1 Build090305 Rel111123

3. permission restrictions

If the project itself requires different permission control for the project team members, you can consider maintaining two projects: one project contains the corresponding source files, and the other is only the compiled files.

4. Module version maintenance

1. Files generally do not need versions, but must have detailed update history records. 2. The module can be maintained by version, which can be differentiated by different folders.

Set up SVN server SVN in Ubuntu 14.04 ://

CentOS 6.2 SVN setup (YUM installation)

Deploy Apache + SVN in CentOS 6.5

Build an SVN server using Apache + SVN

Set up and use the SVN server in Windows + reset the password on the client

Install SVN in Ubuntu Server 12.04 and migrate Virtual SVN data

Build SVN service and migration method on Ubuntu Server

Subversion (SVN) Details: click here
Subversion (SVN): click here

This article permanently updates the link address: