Subversion: Push Your CFML to Production on Commit
Posted by christopher on September 26th, 2006
In the last few weeks I’ve starting toying around with Subversion as a version control system for my ColdFusion work. It’s my first jump into this, or anything like this (i.e. VSS, or CVS). With the help of Joe and his article Setting Up Subversion In An Instant, it was easy as pie. That article, along with all the supporting documentation, should get you started. I should start off by admitting that I have Subversion running on a Windows box.
Since I’m a one man development show, I found it hard to change all my ways. Even with Subversion setup, I found myself doing stupid things like fixing in production, making changes without comitting, etc. To help get rid of some of that temptation, I went out on a search to find a way to let Subversion manage my production server. I wanted to be able to tell myself that Subversion would update production when I was ready for it to. The goal was to keep my hands off the production folders.
And I realized that goal with the help of the Subversion Hooks. What I have since setup is a file called POST-COMMIT.BAT. If I understand correctly, while this batch file will work for Windows, you’ll need to look into Python for your Linux boxes. In any case, the steps I took to setup this “Commit to Production” type situation were as follows:
- Followed Joe’s steps from the article above to setup Subversion.
- Created a repository of my production data.
- Moved my production data into backup, and made my production folder a “Working Copy”.
- Created another working copy in my development environment.
Now I have two copies of my data, one in dev & one in prod. I then setup my POST-INSTALL.BAT file (in bin\hooks folder of Subversion) like below:
@echo off
cls
"c:\program files\svn\bin\svn.exe" log svn://127.0.0.1/MyProjectName/trunk > "\\remote_server\d$\intranet\MyProjectName\revisions.txt"
"c:\program files\svn\bin\svn.exe" update \\remoteserver\d$\intranet\MyProjectName\public > "\\remote_server\d$\intranet\MyProjectName\revision_sync.txt"
What does this do? Quite easily, it first creates a log file for me to reference in my code (this is optional), and then updates the production server’s public share (where my production data is) with the data in the repository. So now when I commit updates in development, it updates the respository I created on my production server in step #3.
Important: If you’ve created a service for SVN on your Windows box, that service MUST be running using an account that has access to the remote server. The default user (LocalSystem) does not have access to remote network shares.
I hope this doesn’t confuse anyone, if it doesn’t come across as well as I meant it to, please comment and ask any questions that you have. Also, this setup would likely work for non-CF projects, I just don’t know enough about Subversion yet to comment on it.









September 27th, 2006 at 11:58 am
I would suggest looking at using “svn export” instead of “svn update” to push the files to production. There are two advantages to this method:
1. Using export doesn’t require you to create a working copy of the repository in your production environment.
2. Export only exports the files without cluttering up the destination with the svn administrative files & folders.
September 27th, 2006 at 2:01 pm
Hi Richard, thanks for your comment! I did look into ssvn export instead of update, and my reasoning behind letting the production server being a working copy instead of an export of the files was that I wanted my mindset to be that my production server was “in sync” with the repository, and not just a dump from it.
In either case, this is an excellent point, and I’m sure anyone else reading the article will find it useful, and may even prefer your method!
October 10th, 2006 at 3:17 pm
Thanks for the info Christopher.
I’ve added a link to this page from my Setting Up A Great Dev Environment post.