What happened to launching a live site from a DVCS clone?

Question

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

• No need to migrate the entire code base with every deployment.
• It is trivial to update the code to any desired version.
• A trivial rollback to a previous version if deployment is severely degraded.

And I do not see any flaws. Having repo files (in my case, one .hg / directory) does not cause problems.

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

Answer 1

This is what I do. The only "drawback" is that you cannot manage versions of the databases or content on the site (loading users). This is not a disadvantage at all, because there is no alternative. As usual, you need a backup script to copy all this content.

This is not an answer, but rather an explanation of modern webapp directory layouts. A very simple Python web application might look something like this:

webapp/ .hg/ webroot/ handler.py 

You set it up so that the web server only serves static content from webroot/ , and if the path does not exist there, it requests python (in this case) for this page.

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

Note: SVN (<1.7) and CVS are exceptions, as they spray their .svn directories under each subdirectory. In this case, it will be webroot/ , so yes, you will need to make sure that you are not using hidden files, but this is usually anyway.

Answer 2

Well, I know one.

If someone can access your .hg directory, they can potentially view your source code. But in fact, access to this directory should be denied by the server or .htaccess files.