This is a mirror of official site: http://jasper-net.blogspot.com/

Top 18 Subversion Best Practices

| Monday, August 2, 2010
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 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

Read more: Aaron Longnion’s ColdFusion Blog

Posted via email from .NET Info

0 comments: