What are you supposed to do with old SVN branches?

Question

We had a SVN branch recently that had been merged back to trunk, and some more work on that feature/functional area was needed. I suggested using the same branch but was told you shouldn't re-use a branch once it has been integrated into trunk (a reference in SVN docs was given, I can't find it now). That suggests a branch is fairly useless once you merge back to trunk, so my question is once a branch is no longer needed, should it simply be deleted or kept?

Answer 1

After some period of time when the project is over, I delete old branches.

You can reuse branch names, but why? Names are cheap. Don't call your branch "work" but get more specific like "data-conversion-phase-1".

Answer 2

I'd recommend against deleting old branches unless they're causing problems. It doesn't actually save you any space, and it makes it easy to look at old versions if you need to.

Reusing a branch after it's been merged to trunk is almost certainly a bad idea.

Answer 3

When I integrate a branch, I move it from branches/ to branches/integrated/. Keeps branches/ clean so its easy to find current work, but also makes it easy to dig up old branches to see what changes were made without needing to do a lot of revision-number archeology.

Answer 4

SVN 1.5 introduced the "mergeinfo" property, which allow you to easily reintegrate branches to the trunk while supporting repeated branch updates. This allows you to create a branch, perodiocally update the branch from the trunk , and finally reintegrate the branch to the trunk ( svn merge --reintegrate ). This is useful for example when you create a branch to fix a bug or to develop a functionality.

The way mergeinfo is implemented doesn't allow you to do a subsequent reintegration, so this is the reason why you are recommended not to reuse the branch.

This is problematic for "release branches" when you want to develop the bug fixes on the release branch and do periodic reintegration to the trunk.

If you want to reuse a branch, the usual pattern is to create a new copy ( branch ) with the same name:

1. delete the branch
2. commit
3. recreate the branch ( branching in a path with the same name )
4. commit
5. work on the new branch

When you "recreate" the branch, in step 3, the mergeinfo is restored, so you can reintegrate in the future without problems.

Back to your question: "so my question is once a branch is no longer needed, should it simply be deleted or kept?" I would keep the branch, so it would be visible in the HEAD revision. Having branches disappear is confusing ( "hey, did we create a branch for release 0.1 last week? " "hmm, I don't remember... check the repo history" )

As for reusing the branch, I would use the convention to never reuse a branch, and if you need to "add somethig to it", recreate it. But in my opinion it is much clearer to use a different branch name. You probably can use a naming convention to identify the branches. For example, the original would be branches/Issue-1 and subsequent extensions branches/Issue-1.0 , branches/Issue-1.1 , etc

Mergeinfo references.

http://blogs.open.collab.net/svn/2008/07/subversion-merg.html http://blogs.open.collab.net/svn/2009/11/where-did-that-mergeinfo-come-from.html

Answer 5

The good practice, while developing a big projects, is to name your branches using names of tasks from project tracking tool: e.g "DEV-1512", "FEAT-512", or bugtracker tickets: "BUG-5142", etc.

When the task is completed, up and runing on the production server, remove the branch. You can always merge back.

PS. Imagine runung svn ls on $repo/branches with 9999 branches ;)