When to create a new branch/tag with subversion?

0
votes

We are developing a PHP project using Subversion. Until now we were developing with the trunk (/trunk), and finally we released the 1.0 version (first to /branch/RB-1.0 and next we've tagged it as /tag/REL-1.0).

My idea is to release bug-fixes as 1.0.x and new features to 1.x, leaving the release of new big versions (2.0, ...) only when we've some important change.

I don't know when is recommended to do a new branch/tag. Only with major version (1.0, 2.0, ...), normal versions (1.1, 1.2, 2.1, ...) or bug-fixes (1.0.x) ?

When I want to release a bug-fix, is it recommended to fix it on trunk or RB-1.0 and merge it to the TAG-1.0 without creating new branches/tags? Tagging/branching must take up a lot of space unnecessarily, isn't it? Thus the version number (1.0.x) won't be reflected in the subversion, only in my changelog.

Is there an "un-official" recommendation about when to branch/tag?

Thx

1
phpsvnversion-controlversioning
While there might be best practices (google for semver + svn and ignore all those results from package managers) this is mostly up to your team to decide. It mostly ends up with tag everything that someone else might use and branch as appropiate. – Rangad
You have some good answers here regarding branching strategies: stackoverflow.com/questions/34975/branching-strategies. Read them and find the blend that suits your situation best. – Ivan Jovović
I've found a good explanation of my doubt here: What do "branch", "tag" and "trunk" mean in Subversion repositories? – Dimas

1 Answers

1
votes

You should NOT merge to a tag. Make a new tag. Tags should be mostly immutable after you make them, or they are meaningless. You should be able to say "tag_1.0" and know exactly what that means, and it should mean the same thing in 3 years.

Don't worry about space. On the server, if you make no modifications when you create a tag or branch, NO additional space is taken for the tag (except for the space taken to store the name and some metadata). In a working copy, it will only take extra space if you check out the entire repository tree–tags, branches, and all–and you should not be doing that anyway. When you do make changes, only space for the changes themselves (the two or three lines that actually changed) will take up space.

As for merge direction: I think the usual practice in SVN is to make your fix on trunk, and then backport that change to all branches you actively maintain. The SVN book chapter on branch patterns discusses this approach. This works well in SVN because SVN can do cherry-pick merges just as easily (or even easier) than full branch merges, and there aren't any real advantages either way on merge direction.

Other projects, especially when using other version control systems, do the reverse. For example, the Mercurial project (which uses Mercurial) grafts bugfixes forward from release branches instead of backporting changes from their "default" branch (equivalent to trunk in SVN). Apparently the merge machinery in Mercurial works better that way, but as I mentioned, I don't think there is a clear advantage either way for SVN.

Branch strategy is entirely up to you, but I somewhat recommend keeping one 1.0.x branch and a bunch of 1.0.1, 1.0.2, etc. tags. Maybe branch again for 1.1.x, 1.2.x, etc.

You can always revisit your branch strategy and rename/delete branches as needed. They'll always be available in your history if you need to look at them again.