SVN usage specification

SVN usage specification 1. Comments must be provided for submission

Clearly submitting comments helps others understand your changes, quickly locate problems, and help the project manager grasp the development progress. Therefore, when submitting code, you must enter a clear annotation that can 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.

 

2. Do not submit code that has not been compiled

Before submitting the code, you must first confirm that you can compile the code locally to ensure that the trunk is always smooth. If a new file is referenced, make sure that the referenced file is submitted together.

L code passes unit test

L The program starts normally.

 

3. Do not submit code that you do not understand

After the code is submitted to SVN, the 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, 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.

 

3. Do not submit your own temporary test code

The code submitted to SVN is a relatively formal code, which is shared with other members. You need to comment out your own temporary test code before submitting it so that it does not affect the development of other members.

 

4. Do not submit local automatic file generation

Development tools automatically generate some files such as projects and temporary files generated by project compilation. After submitting such a file, someone else may conflict with the local environment after the update, thus affecting everyone's work.

Because SVN is on the public network, uploading these files will be too cumbersome, affecting the speed of submitting and updating source code by other members, and wasting the space resources of the SVN server.

 

5. Submit as a whole by function module. Do not submit it too frequently.

After completing a functional module, submit the modifications to the module as a whole. It is not suitable to separate and submit too frequently, resulting in non-synchronous functions.

 

6. Update and submit before submission.

Perform an update operation before submission. This effectively prevents conflicts between locally modified files.

Another possibility is that the submission is successful, but it overwrites the data submitted by other members.

 

7. After submission, you can make convenient updates to your colleagues in a timely manner.

Let colleagues update the code in time, compile the code once, and ensure that the program runs.

If there is a problem, correct the missing files and correct the errors in time to avoid too much impact on the errors.

 

8. Use the lock function with caution.

Use the locked feature with caution in the project. After you lock a file, others cannot modify and submit the file. Although this can reduce the incidence of conflict, however, it may affect the work of other personnel in the project team. Locking is applicable only when you edit files that cannot be merged (non-text files.

SVN usage specification