SVN naming convention: repository, branches, tags

Question

Just curious what your naming conventions are for the following:

Repository name Branches Tags

Right now, we're employing the following standards with SVN, but would like to improve on it:

1. Each project has its own repository
2. Each repository has a set of directories: tags, branches, trunk
3. Tags are immutable copies of the the tree (release, beta, rc, etc.)
4. Branches are typically feature branches
5. Trunk is ongoing development (quick additions, bug fixes, etc.)

Now, with that said, I'm curious how everyone is not only handling the naming of their repositories, but also their tags and branches. For example, do you employ a camel case structure for the project name?

So, if your project is something like Backyard Baseball for Youngins, how do you handle that?

• backyardBaseballForYoungins
• backyard_baseball_for_youngins
• BackyardBaseballForYoungins
• backyardbaseballforyoungins

That seems rather trivial, but it's a question.

If you're going with the feature branch paradigm, how do you name your feature branches? After the feature itself in plain English? Some sort of versioning scheme? I.e. say you want to add functionality to the Backyard Baseball app that allows users to add their own statistics. What would you call your branch?

• {repoName}/branches/user-add-statistics
• {repoName}/branches/userAddStatistics
• {repoName}/branches/user_add_statistics

etc.

Or:

• {repoName}/branches/1.1.0.1

If you go the version route, how do you correlate the version numbers? It seems that feature branches wouldn't benefit much from a versioning schema, being that 1 developer could be working on the "user add statistics" functionality, and another developer could be working on the "admin add statistics" functionality. How are these do branch versions named? Are they better off being:

• {repoName}/branches/1.1.0.1 - user add statistics
• {repoName}/branches/1.1.0.2 - admin add statistics

And once they're merged into the trunk, the trunk might increment appropriately?

Tags seem like they'd benefit the most from version numbers.

With that being said, how are you correlating the versions for your project (whether it be trunk, branch, tag, etc.) with SVN? I.e. how do you, as the developer, know that 1.1.1 has admin add statistics, and user add statistics functionality? How are these descriptive and linked? It'd make sense for tags to have release notes in each tag since they're immutable.

But, yeah, what are your SVN policies going forward?

Answer 1

I use the trunk, tags, branches model.

Trunk: should always be in a stable form. (not necessarily releasable but stable as in no compiler errors) I typically make minor changes and new features that are small and can be completed in less than a single day. If I will be developing something that takes several days and checkins would leave the trunk in an unstable state, I will create a branch.

branches: are for feature development that may leave the trunk in an unstable state. It is also used for "testing" new features and ideas. I make sure to do a trunk to branch update merge to keep the latest developments in trunk in sync with my branch.

tags: are for releases or stable versions of the code that I would want to quickly get back to. Typically I use these for a particular version (1.00) of a module or application. I try not to make any check-ins to tags. If there are bugs, then those changes are made in trunk and will be there for next release. The only exceptions I make are for emergency bugs. This implies that a tag will have been properly QA'd and is quite stable.