A Swiss developer has found the Subversion source control system a welcome integration into his team’s web development efforts.
Maarten Manders discussed the situation facing his web development group. Manders found they needed to implement version control, but considered the venerable CVS inadequate for their needs.
Instead, Manders chose Subversion (SVN) for his group’s needs. He cited a few features other web development teams may find attractive about SVN: atomic transactions, Apache piggybacking, and more convenient branching/tagging. Subversion details more of those features on its website.
With SVN came an assortment of quirks Manders had to address in order to make SVN part of the web development efforts. To overcome them, Manders listed what they would need for SVN:
• A public webserver with the live webspace
• A testing webserver with at least one webspace (working copy) for each developer
• A MySQL server with two databases
• A SVN server
• Some discipline
It’s a familiar setup for web development, one that I have worked in previously but with a brand-name version control system instead of SVN. The setup also kept developers from accessing the live server when moving code from development into production, an important security consideration.
With Manders’ implementation, all the developers work in their distinct working directory on the testing webserver. Code comes from one of the MySQL installations set up as a development database. Changes get committed to SVN, and once the web application’s revisions have been completed, the updated app can be rolled out to production.
Some things belong in SVN, and others don’t. Manders covered the dos and don’ts in his post:
Of course, your code belongs into version control. So do database schemata, templates and graphics. What you shouldn’t put in, is:
• User data – user uploaded files and stuff don’t belong there.
• Database data – don’t confuse revision control with a backup!
• Cached data – it’s temporary data.
• Configuration files – they’re to be created manually.
Don’t even think about putting configuration files into revision control. First of all, they tend to get overwritten and, for example, change your live server’s database. Second, passwords don’t belong into revision control! Instead, you should add default config files with changed filenames, like database.conf.default.
Branching off from the main “trunk” of working code should happen with projects requiring their own versioning, projects that take longer than others to complete, and projects with multiple developers, according to Manders.
—
document.write(“Email murdok here.”)
Drag this 
Add to document.write(“Del.icio.us”) | DiggThis | Yahoo My Web
David Utter is a staff writer for murdok covering technology and business.
