SVN best-practices - working in a team

Question

I'm starting out with SVN. I know the basic commands and understand the base principles. I was wondering if anyone has any tips or best practices for working with Subversion in a team environment.

I can see the benefit of adding reasonably verbose messages when committing code, but are there other things I should bear in mind?

Thanks for all the great answers - they've helped a lot.

Answer 1

Learn about SVN's branching and merging tools and conventions.

The best way to work with other team members is to break work up into complete development features/fixes, then work on individual changes, each in a branch. Then merge the changes back to the mainline branch/trunk when completed/ready/approved to be merged in.

This way individuals can work towards a common goal (either on the same branch or seperate branches) without colliding with other changes.

Your mileage may vary, and this may be overkill for only two or so people.

Answer 2

Consult with your team about their changes, or at least look at the diff very carefully, before fixing any merge conflicts. Ask them to review the merged code themselves to make sure their additions were not lost in the merge.

Answer 3

Well, the basics:

• Create tags before starting QA on a version
• Create tags before risky changes (i.e. big refactors)
• Create branches for released versions in order to freeze the code.
• Make sure that people know to update before starting work on a piece of code and update once again before committing it.
• SVN allows multiple check outs of the same file by different users. Make sure that everyone resolves any conflict that may occur.
• Never use the same SVN account for more than one user. Terrible things may result.

Answer 4

It makes it much easier if you're using good tools that integrate well with SVN. These make it easy to see what's been changed and to then commit all or part of your changes and to frequently update your working copy to the latest version in SVN.

I recommend Tortoise SVN (If you're using Windows) and Visual SVN (if you're using VS).

Also see if you can set it up so that you get e-mail or similar notification any time a change is committed (usually also including the commit message and a list of changed files). Services like CVSDude offer this. I find it helpful to know both that an update has been made and then to have some idea of what's contained in that update before updating my working copy.

Answer 5

Use integration with your bug tracking software. If you use bugzilla, you can set it up so if your comment begins with "Bug XXXX" your SVN comment is automatically added as a comment to the given bug, including a link to you SVN web interface to that revision.

Answer 6

Encourage frequent commits. Teammates new to version control may feel like they need to keep the code out of the repository until "it works right". Teach everyone to commit early and often to find issues as soon as possible. Instead of holding code 'till it works, propose that your teammates create branches for feature that might break trunk. That leads to...

Establish a branching and tagging practice. In addition to branches for features, encourage your teammates to use branches for large-bug fixes. Tag major bug fixes at the beginning and end of the work. Maintain tags (and possibly branches) for production/qa releases.

Establish a policy for trunk and stick to it. One example might be, "trunk must always build without errors." or "trunk must always pass all unit tests". Any work that can't yet meet the standards of trunk must be done in a branch.

Answer 7

Do not commit formatting changes with code changes

If you want to restructure a giant file's whitespace (Control+K+D), fine. Commit the formatting change separately from the actual logical change. Same goes if you want to move functions around in files. Commit the moving separately from the actual editing.

Answer 8

unfortunately, my team doesn't care enough to learn best practices, so we're stuck with the everyone-commit-to-trunk model. it gives me major stability headaches and we're a small team :(

Answer 9

One of the key concepts I always stick by is to commit related code changes together. 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.

Answer 10

One thing that I have seen that reduces broken commits is to have good pre-commit scripts. For example, you can run any unit tests before the change is committed. This will cause commits to be a little slow, but you save time by avoiding stepping on someone's toes and having to apologize. Of course this becomes a lot harder to manage when you have a large development team and very frequent commits.

Answer 11

The answers that people are giving are great. Much of this is summarized in CollabNet's own best practices for SVN.
To repeat:

1. Set up your repository structure (you should have project root with trunk, branches, and tags underneath)
2. Choose your policy re branching (private branches, branches per milestone/release/bug, etc) and stick to it -- I'd recommend more branching rather than less, but no need for private branches
3. Choose your policy re tagging -- more tags the better, but most importantly decide on your tag naming conventions
4. Choose your policy re committing to trunk -- keep trunk as "clean" as possible, it should be release-able at any time

Answer 12

The golden rule for source control: Check In Early, Check In Often

For tips how to organize your repository:

• how-do-you-organize-your-version-control-repository
• SVN Book Chapter 5. Repository Administration
• Repository layout

Answer 13

Besides branching policies et al. (where one size does definitely not fit all), you should have good commits:

• The commit should relate to a single piece of work if possible; a bug fix, a new feature- there should be some 'logic' to what changes you committed
• The commit should have a descriptive comment that will help you locate it browsing the repository history. Most people suggest writing a single sentence at the beginning that describes the whole commit and a more detailed account below
• If possible, you should tie the commit to your bug-tracking system if possible. Trac, Redmine et al. let you create links from bugs to commits and vice versa, which comes in very handy.

Answer 14

A lot as been mentioned already, here are some more:

1. 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.

2. Add a post commit event that would send an email to your dev mailing list (or a one specific for this target) relating to the committed change and ideally the patch for it.

3. Integrate with your bug tracker so that references to commits show up on the bugs / feature requests with links to the diffs. Bug trackers like MantisBT support this.

4. Consider integrating with continuous integration (e.g. CruiseControl.NET), NAnt for Build, and NUnit/VS for unit tests. This way once a user check-ins code or on a scheduled interval the code gets compiled, unit tests are run, and the developer gets feedback of the process. This would also alert the rest of the team if the repository is broken (i.e. doesn't build).

Answer 15

SVN by itself is a good start and some of the other posters have offered some great suggestions on best practices.

The only thing I would add is that you should be hooking up SVN with CruiseControl or TeamCity to drive a Continuous Integration process. This will send out build emails and let everyone know when someone broke the build.

It will be very telling early on who's following your process and who isn't. Might lead to some friction but your team will be better off in the long run.

Answer 16

One thing I've found very useful is the svn:external property which means you can reference directories from other repositories into your own. It's gives really nice ways of organizing your code and data. Some examples are:

1. If you have a separate repositories for code different modules/libraries and reference in the ones you are using. This means that you can have a meta repository for every executable. If it's a small executable that only uses a few modules, you won't need to checkout the entire tree. An effect of this is that you get SVN revision numbers per module.
2. Adding large binary data such as compiled versions of libraries to code repository is generally considered a bad habit, but it can be really convenient. If you just add all versions of all libraries you use to a different repository you can get the best of two worlds. You reference in the versions of the libraries you use into your code repository. When checking out your code repository you'll get both the code and the binaries as well. However the binaries are stored in a large repository which you don't need to backup as rigorously as your source code and the source code repository stays small and contains only text.

Answer 17

One of the examples of integration with bug-tracker and commit policy enforcing could be Trac's svn pre/post-commit hook scripts, which can refuse commit if commit message doesn't reference any ticket in bug-tracker and add comments to existing tickets based on message contents (i.e. commit message may contain something like "Fixes #1, #2 and #8", where #1, #2, #8 are the tickets numbers).

Answer 18

how about this for the comments template:

[task / story xxx][minor / major][comment][follow up comment][url to bug]