Subversion: deleting old feature branches vs. keeping them

Question

I have a subversion repository with the standard layout, i.e. trunk/ and branches/ (and tags/). When working on a bigger change, a feature branch is used, regularly synced with trunk, and later reintegrated back into trunk (using 1.5 now). Pretty standard stuff.

What I am wondering is whether such a feature branch, once finished and merged should be kept around, or deleted. The subversion book occasionally seems to suggest that it is common to delete them, but I've also seen a bunch of Open Source projects which do keep the branches.

I am also somewhat concerned about how deleting a branch will make it harder to keep track of which branches existed, especially when potentially duplicate names enter the scenario (say we search-refactor twice), their commit histories disappearing somewhere in the depth of the repository etc.

On the other hand, branches are used quite a lot, especially with 1.5 now, and I do like the thought of not having to poke through a large list of inactive branches to find the ones I am currently working on.

What are the pros and cons that I am missing? What are people doing?

Answer 1

You can safely delete them. Deleting them doesn't remove them from the repository, the allocated space is never reclaimed, but it sure makes your whole project tree look more cleaned up.

Answer 2

I've been deleting feature branches as we're done, as I like the lack of clutter. There has been minor confusion on the part of some other developers, but since we record revision numbers of commits in our bug-tracking system, it's been pretty smooth. If someone comes by saying they can't find a branch, advice to use the -rrevision flag on their log/diff/checkout/whatever is generally all that's needed.

Answer 3

My team deletes them to keep the clutter down. It's not like the go away after all; they can be retrieved if desired. You are right that it can be difficult to find them again: you need to know a revision number where the branch existed so you tell your client to look at that revision in order to see your files.

We use FogBugz for our project management which keeps track of when things were committed to our SVN repository by revision number. We can use this to determine what revision we need to revert to in order to see our files: we find the feature history in FogBugz, look to determine what revisions the branch existed in, and use that information to jump backwards.

Answer 4

If you are really worried about deleting them, lest they be forgotten, then simply create a folder under branches called 'inactive' and svn move your older, inactive branches into that folder. This might be the best of both worlds for you.