SVN commit tips
I suggest translating a good article with tips on how to commit fixes to the repository The original is written for the T2 project, but almost all of the tips are universal and easily applicable to any other project. And most importantly - they are really useful.
Upd: Though SVN is featured in the title of the article, but the advice given in it is suitable for all the version control systems I know. It is also worth noting that the tips are aimed mainly at team development.
Because fixing changes in SVN can have serious consequences, take time to figure out whether your code will break anything from other developers. After all, the code storage is one for all, and if you break something, it will break for everyone. SVN, of course, allows you to go back to previous versions and this may help solve the problem, but it is better to still prevent the problem than to heroically eliminate it later.
Note Lane: this paragraph deals with compilation, which is not relevant for web development, but if compilation is understood to be free of errors, then the clause makes sense also for web applications
')
Compile the code and fix all errors before committing changes to the repository. Make sure the new files have been fixed. If they are not there, then your code will be compiled locally, and the rest will not be able to do this.
You should definitely make sure that the code compiles with your local settings and on your platform. You should also take into account the effects of your commit for compiling on a different architecture.
Run the application and check the work of those sites that may have been affected by your changes to make sure that the changes behave as you intended.
Make “svn up” and “svn diff” before committing. Get messages from SVN about conflicts, unknown files and more. “Svn diff” will show what exactly you are fixing. Check if this is really what you were going to record.
Comments should be clear to anyone who sees only the log. They should not depend on information outside the context of fixation. Try to describe only those files that are really affected in the changes described in the comments.
In practice, put in the comments all the important information that can not be seen from the output of the diff command.
When you plan to make changes that affect a lot of different code in SVN, report it in the subscription list in advance.
Changes affecting a lot of code in SVN, such as switching to the use of new functions in libraries, can break other code, even if they seem trivial. Such changes can be dangerous because the application must be compiled with old libraries for a number of reasons. By reporting changes in advance, developers can prepare and express concerns before something breaks.
If your fix broke something or has a side effect on other parts of the code, be responsible and fix it or help others fix the problem.
Avoid situations like this: “I don’t know why he falls, but when I do this, he no longer falls” or “I’m not quite sure that this is right, but in any case it works for me”.
Do not abuse your SVN account to push through changes that have been rejected by other developers.
If there is disagreement about changing the code, they should be resolved by discussing them on the mailing list or privately, rather than forcibly replacing the code of others, simply by recording their changes in the repository.
Use the same comment for both fixations — the main fix and the portable one (just add the comment with the main fix revision number). Thus, you can easily see which fixes have already been transferred.
In order to keep your system of accounting errors and SVN synchronized, you must specify the error number in the comments to your commitments, and then close the error in the accounting system.
SVN has the ability to fix more than one file at a time. Therefore, please capture all related changes in several files (even if they cover several directories at the same time) at a time. Thus, you will be sure that the storage will remain in a compiled state (i.e., the code in the storage is compiled without errors, approx. Lane) before and after fixing, as well as sets of changes are easy for merges or rollbacks.
Changing the formatting of the code, such as indentation or underflow, simply blows up the diff, making it very difficult to search for changes in the code if they are mixed with formatting. Capturing formatting changes separately resolves this issue.
PS: crosspost - lobach.info/develop/svn/svn-commit-tutorial
Upd: Though SVN is featured in the title of the article, but the advice given in it is suitable for all the version control systems I know. It is also worth noting that the tips are aimed mainly at team development.
Think twice before committing changes.
Because fixing changes in SVN can have serious consequences, take time to figure out whether your code will break anything from other developers. After all, the code storage is one for all, and if you break something, it will break for everyone. SVN, of course, allows you to go back to previous versions and this may help solve the problem, but it is better to still prevent the problem than to heroically eliminate it later.
Never commit code that does not compile.
Note Lane: this paragraph deals with compilation, which is not relevant for web development, but if compilation is understood to be free of errors, then the clause makes sense also for web applications
')
Compile the code and fix all errors before committing changes to the repository. Make sure the new files have been fixed. If they are not there, then your code will be compiled locally, and the rest will not be able to do this.
You should definitely make sure that the code compiles with your local settings and on your platform. You should also take into account the effects of your commit for compiling on a different architecture.
Test your changes before committing
Run the application and check the work of those sites that may have been affected by your changes to make sure that the changes behave as you intended.
Double check what you are fixing.
Make “svn up” and “svn diff” before committing. Get messages from SVN about conflicts, unknown files and more. “Svn diff” will show what exactly you are fixing. Check if this is really what you were going to record.
Always add meaningful comments to the commit.
Comments should be clear to anyone who sees only the log. They should not depend on information outside the context of fixation. Try to describe only those files that are really affected in the changes described in the comments.
In practice, put in the comments all the important information that can not be seen from the output of the diff command.
Version control system is not a substitute for communication between developers.
When you plan to make changes that affect a lot of different code in SVN, report it in the subscription list in advance.
Changes affecting a lot of code in SVN, such as switching to the use of new functions in libraries, can break other code, even if they seem trivial. Such changes can be dangerous because the application must be compiled with old libraries for a number of reasons. By reporting changes in advance, developers can prepare and express concerns before something breaks.
Take responsibility for your own commitments.
If your fix broke something or has a side effect on other parts of the code, be responsible and fix it or help others fix the problem.
Do not fix code that you do not understand.
Avoid situations like this: “I don’t know why he falls, but when I do this, he no longer falls” or “I’m not quite sure that this is right, but in any case it works for me”.
If you have not found a solution to the problem, discuss it with other developers.
Do not abuse your SVN account to push through changes that have been rejected by other developers.
If there is disagreement about changing the code, they should be resolved by discussing them on the mailing list or privately, rather than forcibly replacing the code of others, simply by recording their changes in the repository.
If you fix the bugfix, consider transferring fixes to other branches.
Use the same comment for both fixations — the main fix and the portable one (just add the comment with the main fix revision number). Thus, you can easily see which fixes have already been transferred.
If you correct the errors recorded in the system of accounting errors, add to the comment number of the error
In order to keep your system of accounting errors and SVN synchronized, you must specify the error number in the comments to your commitments, and then close the error in the accounting system.
Create atomic commits
SVN has the ability to fix more than one file at a time. Therefore, please capture all related changes in several files (even if they cover several directories at the same time) at a time. Thus, you will be sure that the storage will remain in a compiled state (i.e., the code in the storage is compiled without errors, approx. Lane) before and after fixing, as well as sets of changes are easy for merges or rollbacks.
Do not mix formatting and code changes.
Changing the formatting of the code, such as indentation or underflow, simply blows up the diff, making it very difficult to search for changes in the code if they are mixed with formatting. Capturing formatting changes separately resolves this issue.
PS: crosspost - lobach.info/develop/svn/svn-commit-tutorial
Source: https://habr.com/ru/post/57407/
All Articles