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
