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 -- Morality is usually taught by the immoral.
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 -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of BigSmoke Sent: Tuesday, January 03, 2006 2:31 PM To: rails@lists.rubyonrails.org Cc: Wiebe Hedde Cazemier Subject: [Rails] SwitchTower and Subversion branches 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 -- Morality is usually taught by the immoral.
Thanks. Your answer is extremely helpful to me. :-) Best regards, - Rowan On 1/3/06, Tom Fakes <tom@craz8.com> wrote:> 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 > > > -----Original Message----- > From: rails-bounces@lists.rubyonrails.org > [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of BigSmoke > Sent: Tuesday, January 03, 2006 2:31 PM > To: rails@lists.rubyonrails.org > Cc: Wiebe Hedde Cazemier > Subject: [Rails] SwitchTower and Subversion branches > > 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 > > -- > Morality is usually taught by the immoral. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Morality is usually taught by the immoral.
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 Mornini On Jan 3, 2006, at 5:31 PM, BigSmoke wrote:> 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 > > -- > Morality is usually taught by the immoral. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails