On 1/4/2006 7:57 AM, Wilfong Family 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.
In the R project (www.r-project.org) we have a somewhat similar setup.
New development (your Development area) occurs on the trunk. We have
major releases (x.x.0), which are created from the trunk. When a major
release goes into testing, we create a branch named x.x, and start
sending out betas from that. This corresponds to your QA area. At
release time, we create a tag named x.x.0 from the branch; it's a
snapshot of what is out in public. (Things don't work exactly like this
in practice, but this is how they should work!)
Now development of new features continues on the trunk, and bug fixes
happen on the x.x branch. If enough serious bugs are found, we'll
release x.x.1 or x.x.2, etc, all based on a current version of the x.x
branch.
We usually develop bug fixes for any reported bug in the trunk and
migrate them to the x.x branch, but it could just as easily happen in
the other direction.
You can see our developer instructions at
<http://developer.r-project.org/SVNtips.html>. (I should probably
delete the "not well tested" warning at the start; that was put there
when we switched from CVS. The instructions do seem to work. Of
course, if you notice anything that looks particularly dangerous, please
let me know.)
Duncan Murdoch
>
> Any help would be greatly appreciated!!
>
> Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 4 15:05:36 2006