Notes on SVN

---

foreword

Recently, a friend encountered a small pit about SVN at work. He solved it and shared it with me. Although my company does not use SVN, it also gave me a vigilance, so I collected some notes about SVN on the Internet. items, and record them for my future use

Precautions

1. Keep atomic commits

The interval between each commit is as short as possible, a few hours of development work is appropriate. For example, when changing the UI interface, you can submit it once every time you complete a modification or design of the UI interface. When developing a functional module, you can submit it once every time you complete a small detail function test. When modifying a bug, you can submit it once every time you modify a bug and confirm that the bug has been modified. We advocate more submissions, and more insurance can be added to the code.

2. Update before submitting

1. The principle of SVN update is to update and submit at any time. After completing a small function that can be compiled and tested by yourself, submit it carefully. 2. If someone else changes the corresponding file of svn during the modification, the commit may fail. If someone else changes the same file as yourself, it will be merged automatically when updating. If the modification is the same line, then there will be a conflict when merging. In this case, you need to contact the previous developer and negotiate to resolve it together. Conflicts, after resolving conflicts, two people need to test together to ensure that after resolving conflicts, the program will not affect other functions. 3. Pay attention to the list of updated files when updating. If an update is generated during the submission process, you need to recompile and complete some necessary tests before submitting. In this way, we can not only understand which files have been modified by others, but also avoid code errors caused by SVN merge errors.

3. Try to submit the documents you are responsible for when submitting

This can avoid the problem of update failure

4. Coordinate the work plan of the project team members in advance

The project manager should allocate the work plan reasonably. Before each member prepares to modify a certain function, if possible, first talk to the members of the working group about his modification plan, so that everyone can understand your thoughts and the modifications you are about to make to the software, so that It can reduce possible conflicts in the development process as much as possible and improve development efficiency. At the same time, you can also discover the shortcomings of your previous design in the communication with members, and improve your design.

5. Make clear comments on the submitted information

Using SVN in a project team, submitting empty annotations or inaccurate annotations will make other members of the project team feel helpless, and the project manager cannot clearly grasp the progress of the work, and cannot clearly grasp the summary of the submission information. After the error is found, it is impossible to accurately locate the file that caused the error. Therefore, when submitting work, you must fill in clear annotations, which can briefly describe the information of the submitted files, so that other members of the project team can understand the modifications you have made without looking at the code in detail after seeing the annotations.

6. Use the lock function with caution

Use the locking function carefully in the project. After you lock a file, others cannot continue to modify and submit the file. Although it can reduce the incidence of conflicts, it may affect the work of other people in the project team. Usually only when editing files that cannot be merged (such as picture files, flash files, etc.), the lock operation is properly used.

7. Detailed explanation of SVN version conflict resolution

User A modifies the file and submits it to the server after adding content "A user's modification content" is completed, and user B modifies the same file, adding content "B user's modification content" is completed and then submitted to the server. When user B submits the file to the server, it prompts that the version is expired: first, the version should be updated from the repository, and then the conflict should be resolved. After the conflict is resolved, svn resolved should be executed, and then checked in to the repository. After the conflict is resolved, you need to use svn resolved (resolved) to tell subversion to resolve the conflict so that the update can be committed.

There are three options for resolving conflicts:
A. Abandon your own update, use SVN revert (rollback), and then submit. There is no need to use SVN resolved in this way.
B. Give up your own update and use someone else's update. Use the latest version to overwrite the target file, execute resolved filename and submit (select file—right click—resolve).
C. Manual resolution: When a conflict occurs, manually update the target file after communicating with other users. Then execute resolved filename to resolve the conflict, and finally submit.

Solution steps: update conflicts
on the conflicting file (select the file – right-click menu – TortoiseSVN – Edit conflicts (resolve conflicts)), three windows appear: Theirs (the latest version of the server), Mine (locally modified version), Merged ( The merged file content is displayed)

If you need to use which version, right-click on the window, select Use this textblock (use this text block) and
save the file after the modification is completed.
In the conflict directory of user B, select the file-right-click menu—TortoiseSVN—Resolved (solved)
to submit Files after resolving conflicts.

Summarize

The above are some precautions about SVN that I have collected, for my future use and to share with you!