Is it OK to deviate from trunk/tags/branches structure in SVN?

Question

We have our projects in SVN and I am trying to increase the level of automation in our release process.

Historically we developed on trunk and then tagged on release, which entailed a manual (albeit minor) job of doing the actual tag & then incrementing the version number in the source files before the next tag.

We are now using Jenkins, and I have configured our projects to embed SVN revision & Jenkins build number within the resulting EXEs & DLLs etc. I am attempting to go down the route of using release branches rather than tags. So in a perfect world the release branch will never be updated, but we will allow ourselves to apply minor bug fixes.

When using Jenkins & SVN, in my mind, the value of a traditional tag has been reduced, so my current thinking is to not bother requiring a manual tag at all in our release process. It's as if every commit is tagged with the SVN revision number.

So my question is where shall I put these release branches:

1. In branches - But then they are just getting cluttered up with development branches etc.
2. In tags - Because they will be immutable on a good day, but it's breaking with convention? Confusing to new employees?
3. In a new directory releases - Because it's a new convention, it will alert people to its slightly non-standard use.

Will adding a non-standard directory at the same level as trunk cause me some grief with other tools? Tortoise etc.

Answer 1

1. In branches - But then they are just getting cluttered up with development branches etc.

No, I would not do this. Especially if you know that you'll eventually have quite a few of them, I'd separate releases from dev branches (also to avoid confusion for new users).

2. In tags - Because they will be immutable on a good day, but it's breaking with convention? Confusing to new employees?

That's the second best option IMHO.

3. In a new directory releases - Because it's a new convention, it will alert people to its slightly non-standard use.

That's where I would put them. Why not creating a new tag for each bug fix applied (a point release, e.g. 2.5.1)? A new employee has to learn the structures/best practices/code conventions in your dev team anyways, so saying "releases/ is for releases, including minor fixes" is as straightforward as it gets.

Will adding a non-standard directory at the same level as trunk cause me some grief with other tools?

Not that I know.