The situation I'm migrating to is quite similar to Gavin's, and I'd like
to run these ideas by the group. I'm just now developing the repository
and working copies (migrating from an ancient SCCS system of source code
change control).
We're a retail organization. We occasionally have large projects with
full life cycle planning, but more often we deal with small atomic
changes to our production systems, such as: Add a new report version
415.7 to application 415, similar to version 415.6 but adds a new column
and sorts in a different sequence (requires an SQL extract, a report
generator, and a shell script that ties them together).
Planned repository structure:
/trunk - all primary development happens here
/qa - pre-production validation
/prod - approved production systems
/prod/prod-yyyymmdd-rev tags - updated production systems
Process:
All development is done through whatever combination of working copies
makes sense to the developers. They all create their working copies and
update from trunk. As each atomic change is completed, it's tested in
this environment, and then committed to trunk.
After the change is completed, tested, committed, it's passed to the Q/A
team. The Q/A team <svn merge>s the specific trunk changes to the QA
working copy, and does their Q/A testing against that working copy. If
the Q/A fails, they <svn revert> the change and report the failure to
the developers.
If the Q/A succeeds, the Q/A team <svn commit>s this change to the /qa
branch. This commit's revision number becomes our production deployment
control number.
The change is submitted to production deployment, and the deployment
team does the following:
A) Create a /prod/prod-yyyymmdd-rev tag
B) Switch the production working copy to point to the new tag
C) Update the production working copy from the new tag.
Will that work?
Bob Menschel
Senior Systems Analyst
HD Supply, Repair & Remodel
3222 Winona Way # 201
North Highlands, CA 95660
Phone: 916-331-5934 x155
Fax: 866-504-2857
email: Bob.Menschel_at_hdsupply.com
website: http://www.hdsupplyrepairandremodel.com
One Team, Driving Customer Success and Value Creation
-----Original Message-----
From: John Peacock [mailto:john.peacock_at_havurah-software.org]
Sent: Friday, March 07, 2008 4:23 AM
To: Gavin 'Beau' Baumanis
Cc: Ryan Schmidt; Andy Levy; Subversion Users
Subject: Re: Copy svn commmits
Gavin 'Beau' Baumanis wrote:
> @Ryan, I assume that your point is that I would still perform the
> Merge operation - but into a TAG as opposed to a branch.
No, you don't need to merge at all (unless what you have on trunk isn't
completely consistent). Normally, you do all of your development on
trunk and when that is ready to go into production (ALL OF IT, not just
some files), then you create a tag based on the tip of trunk (otherwise
known as HEAD). These tags are then read-only (by convention, though
you can enforce that by a pre-commit hook).
> And instead of relying on "revisions" - I would have the naming of
> the tag to assist with "rolling back" changes made (in error) to the
> production system.
No, you 'switch' to a tag to put your current best release into
production.
Then when you are ready to move then next release into production, you
switch to the next tag. Reverting to a previous state is as simple as
switching back to the prior tag. No merging is involved in this scheme
at all.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-07 19:36:26 CET