How should we set up a web server that supports ongoing development?

Assuming you are doing pure HTML/graphic design, this should be fine. If the sire is dynamic, especially if it is doing anything even vaguely complicated/interesting/tricky, I'd not set up my production box to be my development box.

You want a development environment that is as much like your production environment as possible, and using the same box does accomplish this, but there are a few problems. The most important is that you can bring down your production box testing your new development. Infinite loops, functions with no proper exit, database snafus.... All of these (and more) can negatively impact your production environment.

My first inclination, if you are not doing in-house development, is to rent a second box. My second inclination is to buy a cheap beater box you can replicate the environment on. It is less critical that the hardware be a near match than the software. For example, at my last job, we had high-end small business standalone servers in a colo to handle our production environment. Our test environment was a pair of eMachines.

To recap: if you are doing any dynamic web development, I'd not use production to test it. Get a second hosted environment, or buy a beater box and set it up identically.

I think that the repository information is stored in the working copy, so it won't commit to just any place specified. Also, the information is stored in a database format, not in the familiar directory/directory/directory/file.html folder structure that it's stored on for the client.

What you want is rsync. The developer will do his normal svn checkout from the subversion repo like you outlined, but then when he's ready to push to production, either you or he will log onto the server via ssh and do rsync -av --cvs-exclude /var/domains/dev.mydomain.com/public_html /var/domains/www.mydomain.com/public_html. This list everything that has been updated and at the same time copies to production, except for the .svn directories

It's handy to be able to commit and publish automatically at least for small projects, but a real deployment script (e.g. using rsync as @Kevin M suggests) provides better control and isolation of the production environment. For instance, some frameworks depend on a certain directory setup (for caches, tmp dirs) that it doesn't make sense to keep in subversion. A deployment script can make sure these directories exist have the proper permissions, etc.

You'll need to do a couple things if you want commits automatically published:

1. This article describes how to set up automatic deployment on commits. You may or may not need all of the scripts depending on user setup, permissions, etc.
2. You'll want to make sure your server is configured to not serve up the .svn directories in your published working copy.

Also, if you're depending on installed software (php, python, etc). You'll want to come up with a plan for how to perform upgrades and test them in dev before pushing the software to production. This is harder to do on a single box.