Using hg repository as web site

Question

This is somewhat related to my security question here. Is it a bad idea to use an hg / mercurial repository for a live website? If so, why?

Furthermore, we have dev, test and production installations of our website, like dev.example.com, test.example.com and www.example.com. If it's a bad idea to use a repository for a live/production website, would it be OK to use an hg repository for the dev and test sites?

I'm also concerned about ease of deployment. We have technical and less technical co-workers who will be working with the site. The technical guys (software engineers) won't have any problem working with the command line or TortoiseHG. I'm more concerned about the less technical guys (web designers). They won't be comfortable working on the command line, and may even find TortoiseHG daunting. These guys mostly upload .css files and images to the server. I'd like for these files (at least the .css files) to be under version control, but I want this to be as transparent as possible for the non technical guys.

What's the best way to achieve this?

Edit: Our 'site' is actually a multi-site CMS setup with a main repository and several subrepositories. Mock-up of the repository structure:

/root [main repository containing core files and subrepositories]
    /modules [modules subrepository]
    /sites/global [subrepository for global .css and .php files]
    /sites/site1 [site1 subrepository]
    ...
    /sites/siteN [siteN subrepository]

Software engineers would work in the root, modules and sites/global repositories. Less technical guys (web designers) would work only in the site1 ... siteN subrepositories.

Answer 1

Yes, it is a bad idea.

Do not have your repository as your website. It means that things checked in, but unworking, will immediately be available. And it means that accidental checkins (it happens) will be reflected live as well (i.e. documents that don't belong there, etc).

I actually address this "concept" however (source control as deployment) with a tool I've written (a few other companies are addressing this topic now, as well, so you'll see it more). Mine is for SVN (at the moment) so it's not particularly relevant; I mention it only to show that I've considered this previously (not on a Repository though; a working copy, in that scenario the answer is the same: better to have a non-versioned "free" are as the website directory, and automate (via user action) the copying of the 'versioned' data to that directory).

Answer 2

Many folks keep their sites in repositories, and so long as you don't have people live-editing the live-site you're fine. Have a staging/dev area where your non-revision control folks make their changes and then have someone more RCS-friendly do the commit-pull-merge-push cycle periodically.

So long as it's the conscious action of a judging human doing the staging-area -> production-repo push you're fine. You can even put a hook into the production clone that automatically does a 'hg update' of the working directory within that production clone, so that 'push' is all it takes to deploy.

That said, I think you're underestimating either your web team or tortoiseHg; they can get this.

Answer 3

me personally (i'm a team of 1) and i quite like the idea of using src control as a live website. more so with hg, then with svn.

the way i see it, you can load an entire site, (add/remove files) with a single cmd much easier then ftp/ssh this, delete that etc

if you are using apache (and probably iis as well) you can make a simple .htaccess file that will block all .hg files (or .svn if you are using svn)

my preferred structure is development site is on local machine running directly out of a repository (no security is really required here, do what you like commit as required)

staging/test machine is a separate box or vm running a recent copy of the live database (i have a script to push committed changes to staging server and run tests)

live machine (open ssh connection, push changes to live server, test again, can all be scripted reasonably easily, google for examples)

because of push/pull nature of hg, it means you can commit changes and test without the danger of pushing a broken build to the live website. like you say in your comments, only specific people should have permission to push a version to the live site. (if it fails, you should easily be able to revert to the previous version, via src control)