Re: Using tags to manage releases?
From: Ryan Schmidt <subversion-2011a_at_ryandesign.com>
Date: Wed, 1 Jun 2011 06:42:03 -0500
On May 31, 2011, at 12:59, Charlie Davis wrote:
> First off, we are using Subversion for web site assets.
Yes, please reconsider your strategy. You really *do* want to release trunk (or, if you insist, a release branch) as a whole. You do *not* want to deploy individual files. How could you ever guarantee consistency? You can't. At the last web design company I worked for, before I introduced the team to Subversion, we would manually upload individual files to production by FTP. It was a nightmare of incompatibility. Subversion gives you tools to avoid that by helping you track your code changes and group them together meaningfully into folders, which you can then deploy in their entirety, knowing all the files in them work together.
Consider using trunk as the stable version of your web site. At any time, it should be acceptable to push trunk as a whole to production and it should work. If anybody is going to commit something that's going to break something for awhile, have them make a feature branch, work on things there until they're not broken, then merge it back to trunk.
Whenever you want to release the trunk, tag it. Then push the tag to production. There is a great script to help you with this, called SVN::Notify::Mirror. Look it up. Instead of keying off the log message as you proposed above, it keys off the tag name. (You get to define the pattern in the config file.) So anytime you want to publish your latest version, you simply "svn cp ..../trunk ..../tags/RELEASE-20110601" (or whatever your naming strategy is) and SVN::Notify::Mirror in the post-commit hook in the repository takes care of everything else. Ideally, your developers don't even have the passwords necessary to modify files on the production server, and all changes on the production server happen as a consequence of making a tag in the repository. This ensures all your code changes are tracked and reproducible.
This is an archived mail posted to the Subversion Users mailing list.