Top 18 Subversion Best Practices

My comp

any wanted some SVN tutorials and best practices, so I compiled this list from my own experience and from StackOverflow. These are my preferences for our particular team for the types of projects we work on. They do not all apply to all types of teams and projects, so to each his own. What did I miss?

This is not a “how-to”, but everything how-to can be found for free online at http://svnbook.red-bean.com/en/1.5/index.html

The source for many items here: http://stackoverflow.com/questions/417599/svn-best-practices-working-in-a-team

1. ALWAYS do an “update to HEAD” before doing a commit
2. commit often - as soon as you have working code after some changes you made, make sure to commit the code; this could be as often as every 10 minutes. Just make sure you’re not committing code that breaks the application or otherwise causes errors
3. Commit in small, discrete chunks
4. ALWAYS describe in detail what you did during a commit in the comments, so that other developers or you (in six months) can understand exactly what the commit included. It can be helpful also to include PeopleXS or Jira case numbers so that you can reference the particular bug or feature
5. If you have committed code that has special dependencies (such as database updates or needing to restart ColdFusion), then inform the rest of the team - a short email or a Yammer group is a good place for this.
6. If you are making a lot of changes, do an update often (every hour or so), so that you make sure to get changes made by other people sooner rather than later. Dealing with updates *later* can be a much bigger problem than a bunch of small changes *sooner*
7. Branch the code only when necessary, and merge back to trunk as soon as possible. A release manager or lead developer will handle this
8. Tag before merges, tag major releases, and tag before making sweeping changes
9. Establish a policy for trunk and stick to it. One example might be, "trunk must always build without errors."
10. commit related code changes together
11. The corollary is do not commit unrelated code changes in the same commit. This means don't fix 2 bugs in one commit (unless it's the same fix), and don't commit half a bug fix in each of 2 commits. Also, if I need to add some new enhancement or something to an unrelated part of the system that I then need for some other work, I commit the enhancement separately (and first). The idea is that any change anyone might conceivably want to have on its own (or roll back on its own) should be a separate commit. It will save you tons of headaches when it comes time to do merges or to roll back broken features.
12. If you have files that you don't want in source control (e.g. configuration, compiled files, etc), add them to the ignore list. This way you notice any files that you forget to add by always expecting an empty list of files showing as unknown to SVN.
13. Only advanced, experienced SVN users should do merges, and ideally someone who understands the majority of the code that changed in each branch, so that he can make good decision when there are merge conflicts.
14. Make sure to have updated versions of each branch before merging.
15. Systematically test each feature or bug fix implemented in each branch after merging.
16. Decide the best way to use our repos and make a clear policy for repo layout: http://blogs.open.collab.net/svn/2007/04/subversion_repo.html
17. All filenames and log messages stored as UTF-8
18. If possible, you should tie the commit to your bug-tracking system. Trac, Redmine et al. let you create links from bugs to commits and vice versa, which comes in very handy.

 What did I miss?

My company wanted some SVN tutorials and best practices, so I compiled this list from my own experience and from StackOverflow. These are my preferences for our particular team for the types of projects we work on. They do not all apply to all types of teams and projects, so to each his own. What di ...

Posted via email from Aaron Longnion's ColdFusion Blog