Standard practices for Subversion

Question

Hi,

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 /trunk and /branches

• All work is done in trunk which does not break functionality

• Branch when major structural changes are made or when a feature is being added that breaks core functionality (subject to preference)

• Tags contains stable releases

• Always perform an update before starting work

• Commit changes at end of the day / when a feature has been added

• Commit notes contain a relevant description

• Commit based on feature - don't blanket commit

I am in conflicted minds on the rule to commit at the end of the day and when a feature has been added. I say at the end of the day as to ensure the repository is as up to date as possible. However code at the end of the day may be incomplete/break functionality. However committing only when features have been completed can caused out of date/conflicts?

I'd appreciate your critic on any of my ideas and any of your ideas which I have missed out.

Thanks!

Answer 1

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 2

If you're new to SVN then a good (free) resource is the SVN Book (dead-tree copies can also be bought from O'Reilly).

Answer 3

"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 4

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 5

There are many variations in respect to the source code control workflows. The one we are using is the extension of what you are describing in your post. Your workflow is good enough for minor modifications, but not if you have several teams working on different issues of considerable complexity.

What we do is branch out for every team, than the team can commit to the team (project) branch. Every team is also responsible for synchronizing the team branch with the trunk by merging trunk to branch, preferably after every commit to trunk. After the project is completed, the branch is merged back into trunk (re-integrated) and deleted.

This approach branch - merge...merge - merge back - delete works well for us

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.

Answer 7

Branches are a good idea for making big, possibly-breaking changes. If trunk is being updated at same time, occasionally merge trunk to branch to keep the branch updated.

Commit an atomic set of related changes. Don't do a big commit with unrelated changes all over. This makes tracking specific changes much easier.

You can have multiple checkouts of the same source - useful if experimenting with unrelated changes.

Avoid committing broken code, or code with failing tests, or with other outstanding issues.

Answer 8

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 9

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