Home/ Questions/Q 634363
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T20:17:15+00:00

This is somewhat related to my security question here . Is it a bad

  • 0

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 people (software engineers) won’t have any problem working with the command line or TortoiseHG. I’m more concerned about the less technical people (web designers). They won’t be comfortable working on the command line, and may even find TortoiseHG daunting. These co-workers 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 team members.

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 people (web designers) would work only in the site1 … siteN subrepositories.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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).

    • 0