Detailed SVN commit update seven guidelines

This section explains some of the SVN 's guidelines for submitting updates, and in the previous section we learned about Some of the problems and solutions that SVN submitted, and here we share with you the svn Some guidelines for submitting updates are welcome to come together to learn about SVN submission update issues.

Remember to commit the SVN Update once and submit the Eclipse Auto-generated file, which results in the team update The project does not work after that.

One day I read a few suggestions about the SVN submission update, glued it, and made some cuts and modifications, as follows:

① is responsible and cautious in submitting his own code.

　　SVN the principle of renewal is to be updated timely and submitted in time. When a small function is completed, it can be submitted as early as possible by compiling and testing itself, so that the historical version is saved and can be rolled back when necessary, and the project is last update before starting the day's work .

If there is a conflict in the submission process, you need to contact the previous developer, two people to resolve the conflict together, after resolving the conflict, two people need to test together to ensure that after the conflict is resolved, the program does not affect other features.

② Keep atoms submitted ( do not inadvertently modify and submit someone else's file )

It is best not to submit the entire project at once by submitting only the parts you have modified;

When a feature or file is completed, it is best to submit it. I encountered the completion of a function, did not commit, and then made the changes, the result code appeared a bug, unable to revert to normal when the code.

③ do not submit auto-generated files

　　VisualStudio and other development tools will generate a lot of automated files during the build process, such as . Suo and other configuration files, Debug,release,obj such as compiled files, as well as some other automatically generated, with the compilation of code-independent files, these files should not be checked in when submitted, if you accidentally check in, you need to remove from the warehouse.

④ do not submit code that cannot be compiled

Before committing the code, you must first confirm that you are able to compile locally. The best thing to do with SVN Commit Updates is that the code has passed its own tests before committing.

⑤ don't submit code that you don't 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.

⑥ announce his work plan in advance ( When multiple people collaborate on the same module )

Before you begin to make changes to a feature, talk to the team members about their own plans, so that everyone can understand your thoughts and understand the changes you will make to the software, so as to minimize any conflicts that may arise during the development process and improve the efficiency of development. At the same time you can find yourself in the communication with the members of the shortcomings of the previous design, improve your design.

⑦ uses explicit annotations ( similar to comments written in code ) for SVN - submitted updates , such as the following formats

　　+) indicates an added feature

　　*) indicates a change to some features

　　-) indicates that the file was deleted, or some features were cropped, deleted, and masked.

　　b) indicates that a specific Bug . This section explains the SVN commit update registration completed.

Detailed SVN commit update seven guidelines