What's wrong with running a live site from a DVCS clone?

Question

I see insinuations here and there that it's bad to run a live deployment directly off a DVCS clone, and better to export a clean tree or tarball and deploy that. It seems to me that running directly from a DVCS clone has several advantages:

1. No need to transport the entire codebase on every deployment.
2. Trivial to update code to any desired version.
3. Trivial to rollback to previous version if deployment goes badly.

And I can't really see any disadvantages. The presence of the repo files (in my case, a single .hg/ directory) causes no problems.

Is there really any good reason not to run a live deployment off a DVCS clone?

Answer 1

Well, I know of one.

If someone can gain access to your .hg directory, they could potentially view your source code. But really, access to this directory should be disallowed by the server or by .htaccess files.

Answer 2

This is what I do. The only "disadvantage" is you can't really version-control the databases or site-generated content (user uploads). It's not a disadvantage at all though because there's no alternative. Just as usual, you need a backup script to copy all that content out.

This isn't an answer but rather an explanation of modern webapp directory layouts. A very simple Python webapp might look something like this:

webapp/
  .hg/
  webroot/
  handler.py

You would set it up so that the webserver only serves static content from webroot/ and if the path doesn't exist in there it asks python (in this case) for that page.

Since none of the server-side source-code is within webroot/, it cannot be served (unless you have a python directive ordering it to serve source code). The same applies to the .hg/ directory.

Note: SVN and CVS are exceptions as they spray their .svn directories over every subdirectory. In this case that would include webroot/ so, yes, you'd need to make sure you weren't serving hidden files but this is commonly the case anyway.