Standard practices for Subversion

Question

I\'m wondering if there\'s any other factors to consider for standard practice of using Subversion.

The few I have are:

• Directory structure of /tags /tr

Answer 1

"However committing only when features have been completed can caused out of date/conflicts?"

If the change is so large that you are worrying about this, then you likely should have branched. This would allow you to make smaller commits if incremental work without breaking the build, and leave a clear history after merging into trunk.

Answer 2

If a "feature" will require more than a few (4-6) hours to complete, I would either

• divide the "feature" into subtasks that can be completed in a few hours and checked into source control
• create a branch
• both of the above

Answer 3

You should always do an update before committing, to prevent possible conflicts with other commits made by other people and painful merges.

Also, every commit should contains something meaningful, like a bugfix, or a new feature, or some improvement to an existing one, something that can be meaningful described in the log message. A source control tool is not a backup tool, so "end-of-the-day" commit without a meaningful content should be avoided.

Answer 4

Some more notes:(have tried not to repeat what has been already said..)

Branches:

1. Besides branching for the large chunks of feature development mentioned above, you can branch when you need to work on post-release fixes, while parallel work is progressing on the mainline/trunk.

2. Reverse merge regularly if you are using branches that live for long without getting merged to mainline development. This will help to stay in sync with the trunk development and minimize complications of a big bang merge.

3. Pay attention to the way you name your branches. We try to name the branches after the milestone it is based off. It helps when you need quick diffs or reports or even while browsing for something, if the names are self explanatory.

4. Since in SVN the branch is a cheap copy, we try to always branch at the root of the project directory (if its the folder trunk itself, then the branch will be off trunk) -- this avoids confusion later about who branched off where and avoids having to run commands to find it out. And if you need to checkout stuff from a branch everythign under the branch is available to you --- if you happen to need it.

Commits:

1. I vote for commits often and in logical chunks so you can tie the related files by a common commit message. This is great for when you want a log and the reporting is done in chunks with the bunch of files all tied up neatly with relevant comments.

2. I vote for frequent commits, if not everyday. It is a mindset. Once you see the benefits of having early commits (of course after the developers have checked for basic compilation errors and have run unit tests in their dev box), you'd be happy to catch those early bugs/build issues. If you plan to run nightly builds or use a continuous integration tool , you'd be better off getting the folks to commit as early as they can, to help get an insight into the integrated streams of work and run tests on them.

Tags:

1. Nail the release naming conventions - although this seems trivial it helps to have good tag names. Also ensure that the commit comments for tags specify exactly why you are tagging this version of the repository. We tag only when we do milestone builds, so in our case, we map the tag commit messages with the continuous build number (cruise build tag) we are using for the given build. It also helps to have the release numbering scheme and the fields defined so you can use these for the tags.

Answer 5

I've recently been involved with the improvement of the software configuration management (SCM) techniques in use at the company I work for. We found that both "branching for development" and "branching for release" work rather well.

A good book on SCM patterns / standard procedures that I found helpful is "Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Berczuk and Appleton".

Answer 6

I'd try to commit as often as possible. To allow this, you have to make sure that the code you write either is not yet used, or is such that all the tests pass. If you stay in one of those two modes (the latter being much better than the former), then you should not have to worry about those large periods when you can't commit.

TDD helps very much in this respect.