SVN Dos and Dont’s

The Dos and Dont’s

Dos	Don’ts
Check out the latest revision before start working, and check your changes back in as soon as possible.	Don’t use svn locks. Commits in subversion are transactional and locks are almost always unnecessary.
Commit often, one change at a time. Easier to read and debug.	Don’t include multiple changes in a single large commit.
Look at the diff before committing, make sure you can answer the question: what are you changing? You’ll need the answer for the next point.	Don’t tidy up the code while making changes. If tidying up is necessary, do it in a separate commit (see Bruno’s comment).
Document changes in the commit message, use the -m switch in the command line or the entry field provided by TortoiseSVN or other SVN-GUIs.	Don’t leave the message field empty. If the change requires more than a few lines of explanations, consider breaking it down into multiple commits.
Reference tracker tickets in the comment when applicable.	Don’t fill the message field with prose. If the nature of the change requires a lot of explanations (e.g. new API), provide documentation in separate file(s) and refer to it.
Use svn:externals or scripts to fetch and unpack external dependencies.	Don’t commit external dependencies (e.g. “SDK”) to the repository.
Discuss conflicting choices and seek consensus on the hugin-ptxmailing list. Consider adding alternative functionality rather than replacing existing one.	Don’t override other committers code just because you disagree with their solution.
Consider branching when the development work you initiate will take more than a day or two to complete.	Don’t regret the code lost because you did not commit it right away.
Test your changes locally before committing. If you must leave unfinished or untested work, wrap it in an always false condition so that it won’t affect other users.	Don’t commit changes without having them tested locally.
Keep in mind that the code is for multiple platforms. Ask users of other platforms to check if your changes affect their platforms adversely.	Don’t ignore other platforms and silently break the code for them.
Ask on the hugin-ptx mailing list for advice. If you are unsure whether you should commit, provide a patch that other users can apply and test.	Don’t be shy. Your contribution is always welcome. If it breaks something, we’ll work together to fix it.
Give credit where credit is due. If adding to SVN code from a third party patch, mention the third party as originator of the code. If making a change on user feedback, mention the user.	Don’t commit third party changes without testing and understanding what they do first.
Keep files that do not require version control in appropriate resources such as Flickr, Vimeo, or webspace that is donated to the community.	Don’t clutter the repository with files that do not require version control and use a lot of space/bandwidth, such as podcasts and presentations.