# SwitchTower and Subversion branches **URL:** \ **Category:** Rails\ **Created:** [January 3, 2006, 11:33pm UTC](https://www.ruby-forum.com/t/switchtower-and-subversion-branches/89143 "2006-01-03T23:33:35Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [January 3, 2006, 11:33pm UTC](https://www.ruby-forum.com/t/switchtower-and-subversion-branches/89143/1 "2006-01-03T23:33:35Z")
I’m working on a Rails project that needs to be deployed in the near future. To enable prompt responses to bug reports, me and my coding partner were thinking to use the following SVN repository lay-out/policy. We’re using trunk/ for our main-line development. Whenever we deploy something from our trunk, we first want to make a branch (e.g. branches/1.x) and then derive a tag from this (e.g. tags/1.1). We thought this policy’d make sense because it would allow us to respond quickly to problems in a deployed version by checking out the branch from which the exported tag is derived and then deriving a new tag from the committed changes. Often times the trunk contains active developments that simply make it unsuitable for deployment. However, the SwitchTower examples seem to be based on deploying directly from trunk. I’m wondering: how do people deal with having to fix something in a release without going back to the trunk to do this. It seems to me that not having releases reflected in SVN branches or tags is cumbersome when having to resume development on an earlier branch. I’m aware I could just be checking out the trunk with -r [time\_of\_release]. I could imagine doing this and then only creating a branch only when we need to fix something in a branch. Thus: svn copy -r [release\_date] file:///svn/db/trunk file:///svn/db/branches/new\_branch svn checkout -r [release\_date] file:///svn/db/new\_branch However, this would imply that I’d have to tell Switchtower to then deploy from that new\_branch for these occassions, which hardly seems convenient. And, I’m simply afraid to deploy an unsuitable version by accident. I hope I’ve made myself somewhat clear on this confusing subject, - Rowan ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [January 3, 2006, 11:55pm UTC](https://www.ruby-forum.com/t/switchtower-and-subversion-branches/89143/2 "2006-01-03T23:55:04Z")
In your deploy.rb file you can set the location of the Subversion repository to get code from. You could specify a branch location here: ``` set :repository, "svn://server/branch/app" ``` You can also set a ‘revision’ property that is the revision of the tree to get - defaults to the latest revision. You can set this on the command line to switchtower: ``` switchtower -vvvv -r config/deploy -a deploy -s revision=42 ``` It doesn’t seem possible to use a tag name, but it is possible for you to work out of a branch and use the specific revision of your choice. In fact, you can set the repository on the command line too: ``` switchtower -vvvv -r config/deploy -a deploy -s ``` repository=svn://server/app/tags/1.1 ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [January 4, 2006, 2:18am UTC](https://www.ruby-forum.com/t/switchtower-and-subversion-branches/89143/3 "2006-01-04T02:18:44Z")
Thanks. Your answer is extremely helpful to me. 🙂 Best regards, - Rowan ---
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [January 4, 2006, 5:43am UTC](https://www.ruby-forum.com/t/switchtower-and-subversion-branches/89143/4 "2006-01-04T05:43:45Z")
Switchtower seems (from the docs I’ve read) to support the stable mainline development philosophy where you work on a branch and merge development branches into the head. Have you considered working that way? It’s actually pretty nice to have a development branch _per feature_ and when you’re done with some specific work, merge it in… That said, my natural inclination is to work the way you’ve described. – – Tom M.