views:

69

answers:

2

I'm starting to use Mercurial on my web server (in this case MediaTemple's Grid). I've used SVN previously, though I'm not an expert of version control systems. I'm just needing a little help with clearing up some confusion with getting it set up optimally.

I have a 'data' folder which is outside the web server root and that the browser cannot access. It was recommended to me before to have my Mercurial repositories setup here, then I would clone from here locally on my computer. I would also have a 'domains' folder that is basically the web server root and inside there is my actual domains where my websites are actually served to the browser - these would need to be updated from the 'data' repositories too.

But with this in mind, after setting it up, it seems inefficient... I'm cloning to my local (that makes sense), adding, committing, pushing. That's fine... But then I'm then updating in my data repository folder and then updating in my domains folder to actually update my websites.

Surely, I don't actually need this 'data' folder for repositories? Wouldn't my actual live 'domains' folders be the main repositories themselves? So I'm cloning locally and updating from these? Please help me clear some confusions with all this (if you can).

A: 

It's strictly a matter of personal preference. Some folks make their live websites also the "master" repo, and some make it a clone of an elsewhere located repo. What you're doing right is serving your sites from directory in the repo, that's a good choice.

Some considerations as to whether you might want separate 'data' clones independent from the web root clones are:

  • do you want to have multiple heads in the same branch which might confuse the person updating the main repo?
  • do you want a repo to which people you don't trust with editing the live website can push so that a trusted admin (you?) does the push/pull from data to webroot?

One thing to note is that in the 'data' repo you can do hg update -r null which gets rid of the working copy (but keeps the repo!), so that the diskspace used is almost zero (assuming it's a clone of the webroot they'll share the same underlying files at the FS hardlink level).

Ry4an
So you are saying that this way is fine... The local repo, the 'data' repo and the live domains repos. I suppose, like you say, if others are working on this code, they can all push and pull to the 'data' repo and not have access to the main live sites... That'll be left up to me. That makes sense. It's interesting what you say about the getting rid of the working copy, so my 'data' repo can literally be just the repo and no files at all - is that what you're saying?
littlejim84
A: 

I do have a repos (data) folder outside the website root, containing various repositories, and served through hgwebdir on a separate domain (hg.mywebsite.com).

However, my website’s repository I do store in the httpdocs directory of the main domain. I test on my local environment and then pushing my changes to the server will also publish them.

To achieve this I have this in my hgweb.config:

private/mywebsite = ../../../httpdocs

And this in that repository’s hgrc:

[hooks]
changegroup.update = hg update

This hook will update the working directory to the tip whenever changes are pushed. Of course I have also added a rule to the Apache configuration to ignore the .hg directory, and on the subdomain hg runs on, a rule to require authorisation for accesses to the private/ paths.

An alternative would be to instead host the repository together with the others, and then ‘hg archive’ into the httpdocs directory. A little more secure, a little slower, and as for convenience I would say it’s 50-50.

p.s. also adding a hook to forbid creation of remote branches may be a good idea, if people who might do push -f can access your repositories.

Laurens Holst