Discuss: I Wonder What This Button Does

by Mike West

11 Version Controlled Websites

I understand the usage of SVN to control desktop software, but it would be helpful to see an example of how to use it for a website.

Is the site itself the repository? Or is the site a checkout of the repository? Am I going to need to run a server on my local machine, and then sync my changes up to live through SVN? What about the DB? When I make quick changes to the stylesheet or a plugin, will I be jumping hoops just to get them launched?

I’d be interested in an article explaining this in more detail. But for situations where I’m the sole programmer, I find it just as convenient to edit over FTP in a dev directory, and then rsync it with a live directory.

posted at 12:48 am on July 26, 2006 by Mike Purvis

12 Re: Version Controlled Websites

There’s several ways to go about doing this.

Is the site itself the repository? Or is the site a checkout of the repository?

No. Subversion stores files in an opaque format that webservers can’t read. It would be a checkout.

Am I going to need to run a server on my local machine, and then sync my changes up to live through SVN?

The easiest way is if you have an external Subversion server that the production server can access, then all you need to do is `svn up` from inside the public html directory.

However, I do manage a website that has a local repository that’s not web readable. In this case, I use `svn export` to create a tarball of the website, upload it, and extract, overwriting previous files. (an extra note: I usually tag these like DEPLOY-DATE). It’s slightly clunky though, I strongly recommend a public SVN server.

What about the DB?

It is a tricky issue. My recommendation, based on the way MediaWiki does it, is to try to keep your database as stable as possible. When you do need to change it, make sure that you make a update.php file that can detect what version of the schema you’re using and update accordingly (run from shell, of course).

When I make quick changes to the stylesheet or a plugin, will I be jumping hoops just to get them launched?

For an external SVN server, all you need to do is `svn up` and the changes are live (if the repository and the webserver are on the same server, you can setup a post-commit hook to instruct the webserver to update. I have this setup on another of my websites).

Internally speaking, you could just upload just the file real fast, but I’d recommend tagging that snapshot anyway so that you can redeploy all the files if necessary.

I’d be interested in an article explaining this in more detail

Read the Subversion Book

But for situations where I’m the sole programmer, I find it just as convenient to edit over FTP in a dev directory, and then rsync it with a live directory.

You should always use version control, even on single person projects. I always use version control on all of mine. ;-)

posted at 01:10 am on July 26, 2006 by Edward Yang

13 Nice piece of advocacy

I strongly recommend any kind of version control. Especially Subversion. Heck, I even use it for non-programming related stuff: short stories, configuration files…

In that sense, this is good advocacy. However, anyone who’s already using Subversion will find this article kind of useless. I for one would be interested in seeing a survey of managing non-versionable properties, like database schemas/formats and external environments (PHP 4.3.11 vs 4.3.10 can be a real bugger to fix).

posted at 01:13 am on July 26, 2006 by Edward Yang

14 self control - the enemy within!

Well written — what a relevant topic!

I can’t tell you how many times I’ve had the sinking feeling of version OUT-OF-control. Sadly, it was usually because I opted not to use a perfectly usable system that was already in place. Part of my battle with version control is controlling the developer (in this case, myself) and getting them comfortable with checkin/checkout as part of their normal work flow.

posted at 04:53 am on July 26, 2006 by Walter Stevenson

15 Chinese Test

试一试中文是�?�显示无误:) wanderful!!!

posted at 05:28 am on July 26, 2006 by Silbo Su

16 Advocacy indeed. :)

Mike: I think Edward’s explanation was pretty much spot on. When I’m deploying a website, I use Subversion more or less just like I’d use rsync.

I have Apache/PHP/MySQL (or Django, or Rails, etc.) running locally on my home computer, with a virtual host pointing at the trunk of my working copy. As I work, I use Subversion to manage the important changes to the code, committing or rolling back as necessary. When I’m ready to deploy my changes to the production server, I make sure that everything locally is safely committed, and then tag the current revision as “YYYY-MM-DD_Deployment”.

Pushing out my changes to production is then a pretty trivial task. I ssh into the production server, navigate to the document root, and check out that tagged release by running svn co. That merges all the changes into production, so all that’s left is to test one last time to make sure everything worked, and then you’re good to go.

This is generally faster for me than uploading changes via FTP, because I don’t have to play around in various directories trying to remember all the files I changed. The repository keeps track of that information for me, all I have to do is ask it nicely.

The value added by always being able to roll back to a previous release by checking out the previous tag is immense. It does sound like a little extra work, but the overhead is minimal. I find that working through this process, even for one-off changes, quickly fades into the background.

As an aside, if you do use Subversion to deploy your sites, I’d suggest reading Preventing SVN Exposure to make sure you’re not inadvertently making sensitive information available.

Edward: I agree with your assessment of the article; it’s very much focused on advocating the use of revision control to people who currently aren’t using it. Unfortunately, that’s a huge group of people.

Walter: You’re right! It’s a habit you’ve got to adopt to get the most benefit. That said, even only periodically committing your files back to a repository is better than never using it in the first place. :)

posted at 09:39 am on July 26, 2006 by Mike West

17 RE: Version Controlled websites

Subversion lets you create hooks on various actions including post-commit. Using that, it’s fairly trivial (for someone with reasonable perl or shell ability) to automatically update your website each time you ‘tag’ a release, and update a staging website each time you commit.

Running your website as a checked-out repository might not be a good idea due to the svn cruft lying around (make sure your setup doesn’t allow viewing of ‘hidden’ files and directories)

posted at 11:10 am on July 26, 2006 by Rick Measham

18 The Article title .. buttons?

While I’m here, let me say that the headline was a poor editor decision: the article is abour revision control, not buttons.

Back in April Slashdot talked about the way headlines have changed from being ‘sensational’ to being descriptive: online we’re hit by so much information you need to put some info in the headline to grab our attention rather than just making it ‘loud’.

In this case, figuring ALA knew this, I guessed this was an article about buttons. Oh well .. great article anyway :-)

posted at 11:19 am on July 26, 2006 by Rick Measham

19 Untitled

I totally agree to Rene that working with some kind of version control system should be in the university schedule of computer science students. I (as an employer) often find young applicants for my job positions never ever have worked in a team and they don’t even know what version control is good for. I really get a headache if I see them working on their local drive with no backup at all. I used to work in some 100+ people projects so I know the need of version control. But even if you have a version control system installed developers will need to use it in a proper way. For example if you move files to another directory some copy the files and delete the old ones. So all the history is gone (ok, it’s still there, but difficult to compare).

posted at 05:03 pm on July 26, 2006 by Andreas Berg

20 svn and Dreamweaver

@Edwards: subversion has a WebDAV interface, which make it comfortable to use with Dreamweaver.
Dreamweaver sees the repos as usual with FTP.
Every ‘upload’ will generate a commit. You lost the possibility to make custom commit messages, but I think it’s still an interesting use because it integrates itself smoothly in your workflow.

It would be great if Adobe will integrate Dw with svn, i.e. using Design Notes as commit.messages

posted at 07:07 pm on July 26, 2006 by Flavio Curella