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.

Answer 2

camelCase? No, we don't put any restrictions on names, except that spaces tend to be discouraged. The content is what matters, not the presentation. As long as the name is clearly defined what it does, we're happy.

I think the biggest change you can make is to put all your projects in a single repo at the top level.

We don't use branches or tags directories as we have many hundreds of projects, each divided up into versioned groups (ie we have a base platform that is versioned, and a lot of plugins that live underneath each base version number)

eg:

base v1
  +--- moduleA
  +----moduleB
base v2
  +--- moduleA
  +----moduleB

We've thought about putting a tag branch underneath each of the module directories, but we nearly always deal with the head version, so its not an issue for us. We regularly merge changes from older base version modules to the new - eg make a change to moduleA for base v1, the changes are merged into base v2's moduleA. We don't go backwards unless necessary.

Every module has a release note with it, that describe the version number and the changes. The log comment has some of the description and version number in there. This makes it very easy to get previous versions out without having to have lots of tag branches that are uniquely named. If we did start using tag branches (its been suggested) then we'd make a full path copy into the /tags directory), we'd still merge onto a single tag branch and put a log comment marking the release number, we just have too many modules to manage them as 1 tag folder per branch. And no, we never make changes to historical revisions - if a customer needs new functionality, they have to upgrade to the latest version (which is never a problem until they change the base platform version)

We don't use branches either, as we tend to work on the head version of each module, if we do need a branch for a major set of changes, we will branch at the base level, so we'd create a "base v2 - performance" branch and branch everything. This makes it easy to group a lot of changes together, as it works out that way best for us. Branching individual modules would incur too much clutter in the repo - as we have a couple of hundred, it'd be easy to lose track of them if we had branches per module.

Yes, we make changes on the trunk, but this is ok with our workflow - things don't get committed until they're ready to go. All changes that are made to the older base versions are bug fixes only, and we have too many modules to manage them in a full dev-test-release cycle. We fix, if it proves to be a bad fix, we fix again. We sometimes change this approach for bigger developments and create a branch on a branches folder (off the root). The branch path re-creates the path to the original module (so its easy to tell which it is, and merging back is as easy as changing /branches to /trunk at the beginning of the path).

The only issue we've come across in this system is when we put a module in a web app's project (redmine). We wanted to have a single redmine project for all versions of a module, but our layout was such that it became a bit difficult to give a root to the repository. If we could associate a repo path with each version in redmine, then this limitation would disappear.

Its not necessarily the best for everyone, and I'd recommend using branches more, but this works for us (partly as it was the way we worked in a previous source control system that was "safe" and didn't support branches/merging).

Answer 3

I have trunk, branches, tags, and workspaces under the repository root.

• trunk - not used to avoid a confusion
• branches - release branches, one release life is about a year, named by product name acronym and current year (LDN_FSHCHPS_REL_2010)
• tags - immutable release/patch labels (done with svn copy), automatically generated from the timestamp (LBL_20100526180134 = 2010-05-26 18:01:34), releases versions are generated from the same timestamp like v10.05.26.180134 so it is easy to map label to version
• workspaces - feature/individual developer's branches, grow from branches/LDN_FSHCHPS_REL_2010 for new development or from tags/LBL_20100526180134 for patching, branching is done with svn copy, backmerge -- with svn merge, reintergration is done with svn merge --reintegrate. workspaces are named just like WS_ where is automatically generated by script (autoincrement-like)

Everything is in a single repository with hourly/daily/etc. backups. All steps like branching, labeling, merging, and building are scripted for convenience and stability (scripts check repository consistency).

Branching/merging is allowed for second level directories only, and only complete merges, not individual files/dirs (say branches/LDN_FSHCHPS_REL_2010 --> workspaces/WS_345) to enable automatic merging and to avoid problems with subtree merge info (and also to ease the rootcausing of the merge problems when they happen)

Answer 4

Right now, we're employing the following standards with SVN...

Normally, Tags are mutable. The reason you tag a release is so you can apply bug fixes while development continues on the trunk. Of course, the same bug fixes have to be applied to the trunk.

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

We're a Java shop, so all of our projects are named gov.bop.project. :-) Subversion works with any names.

If you're going with the feature branch paradigm, how do you name your feature branches?

We go with the number generated by our incident reporting system. This aids auditability.

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

We've found that yyyymmdd dates work better over a long timeframe.