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 /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

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.