SVN usage specification in Collaborative Development

SVN usage specification in Collaborative Development

 

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 the same file is changed by others, the file is automatically merged during update. If the modified row is the same, a conflict occurs 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 a 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 team, if empty or inaccurate annotations are submitted, other members of the project team 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 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 (such as instance files and flash files.