On 1/4/06, Wilfong Family <nikeaa@qwest.net> wrote:
> I am relatively new to Subversion, so I was looking for advice on how
> the following could be setup in Subversion. We currently work in Visual
> SourceSafe, and are not totally satisfied with it. I want to have a
> plan all laid out prior to possibly presenting a change to Subversion
> to management.
>
> We have three separate areas where we work on our code:
> 1 Development – this is where we do our development work for the
> next release (ex. V3)
> 2 QA – this is where the quality assurance department does their
> work on the current release (ex. V2)
> 3 Production – this is the last production release (ex. V1)
>
> The flow is as follows:
> • If there is a bug found in production, we fix it in production,
> then move the code changes to the QA and Development versions.
> • If there is a bug found in the QA version, we fix it in QA and
> move the code changes to the Development version.
>
> When we are ready to release a new version of the software, we move the
> version that is currently in QA to Production, the version in
> Development to QA, and we start development work for the next release
> in Development. So with the version numbers from above we now have V2
> in Production, V3 in QA, and we are starting work on V4 in Development.
>
> What I need advice on is how to setup the repository and if and where
> tags/branches should be used.
Sounds pretty standard to me (have you read the book yet?). Dev
should be the trunk, then create a branch for your first QA drop.
Upon completion of QA, branch that to production. Merge fixes from
production to Dev & QA, and merge QA fixes to Dev.
Received on Wed Jan 4 14:31:31 2006