What's a good way to version control a website development project that includes MediaWiki and WordPress installation?

I am trying to figure out version control procedures for a website that includes MediaWiki and WordPress installations. I just started thinking about these and am probably asking too quickly and vague questions.

Say the website root is

~/public_html

There are various static HTML pages

~/public_html/page1.html
~/public_html/dir/page2.html
...

And there are installations of MediaWiki

~/public_html/wiki/

and WordPress

~/public_html/blog/

and possible other webapp that have database backend.

there are a few questions not clear to me

• If I use Subversion, what's my first step? As I already have a /public_html running on my web server machine, do I need to download the complete /public_html to my local development computer first and then commit it to my svn server (separate) as a project? I have other software projects that are version controlled using subversion.

• If I use Subversion , when I deploy, do I just check out, i.e. the website that's used by the server will be a working copy of the repository? Will the Med开发者_运维技巧iaWiki and WordPress be properly versioned? Also what about the .svn directories? Won't that be exposed?

• besides version control the files in /public_html how do I backup databases in a way that's streamlined with the files in public_html?

• If I use Mercurial instead, I can use public_html as the repository and don't necessarily need to clone out a repository?

I am using source control, scripts and deployment procedures to manage few web application projects like wordpress, phpbb and custom web applications. Over the years, I refined these and now I have a nice framework that seems to work well for me, so it may suit others facing similar chalenges.

Here are some general points about the overall strategy:

• I never have SCM and source files on the production server. I don't see any reason to put it there and usually I don't want the repositories exposed in case of server breach. The applications on the production server only have the clean latest stable revision. No project files, docs, unit testing, etc. Anything that isn't needed isn't there. I find this very important both from security and application stability points of view.
• Not to turn this into SCM debate but I found that for my purposes, mercurial (and git) are better than SVN in any aspect. You don't need any "server" and the repositories are easier to maintain.
• I keep separate repository per project. Mercurial repositories are cheap and lightweight. Keeping every project in its own repository gives great flexibility. So no one big repository for "public_html".
• I work with local mercurial repositories on the development machine. Everything is backed up as is (using whatever backup strategy - additional machines, external drives, cloud backup). Sharing code is as easy as just giving the project's directory. Sometimes I keep repositories on dropbox, so I can access them from anywhere.
• Deployment is done automatically by a deploy script(s) (more details later). Which exports the desired revision, edits it and uploads it to the server.
• Databases dumps are not stored in the SCM. It is not practical for any real project. I store a dump of the database structure in the SCM and update it any time the structure changes (I use mysql dump or phpmyadmin for this). Sometimes it makes sense to store a dump of a skeleton data in the SCM along with the structure (tables with defaults, lookup values etc).
• Database backup is done by automatic script (automysqlbackup works well) that runs on the production server. Dumps the database, archives it and rotates the files (monthly, weekly, daily). There is also a script that downloads the backup dump files to an off site location daily. This works well for projects with relatively small-medium data sizes. Obviously, this will need to change for large databases.
• I usually keep separate database instances for development and productions. Messing around with the production database as little as possible. When I need to test/debug something, I update my development database with a copy of the live data.
• Sometimes I have a second copy of my application on the production server for staging/unit testing but that's too much to describe here.
• All deployment is tunneled over SSH, which is the only connection allowed on the server (except for http/s, of course). I keep SSH key file on the development machine. Alternatively, you can use VPN as the tunnel.
• I am assuming linux/BSD production servers. All this will be totally different (and usually harder) on Windows server. I used these procedures on Windows, Mac and Linux development machines, all the tools are available on all.

So, to answer some of your questions, I'd do it the other way around. Start with a working environment on your development machine (complete with web server and database). Have your applications work and tested there. Commit changes to the local repository as needed. Once the application is ready for deployment, run the deploy script to automatically update the production site.

My deploy script do something like this:

• Export the desired revision to a local temp deploy directory (mercurial, git, SVN all have export commands that create a working directory from your repository)
• Modify the deployed directory to make it suitable for live deployment. This includes modifying config files, changing database names, paths, log settings, debug levels etc. Using scripts, sed, awk, grep or whatever command line tools needed.
• If needed, generate version.txt (or whatever name) file from the SCM revision data, deploy date, etc. This will be uploaded to the server.
• Add my SSH key to the SSH agent (to avoid using passwords each time).
• Use rsync, tunneled over SSH to sync everything to the server. The server will need to be properly configured as the rsync destination. Use rsync exclude/include filters to exclude everything not needed (often it is .* except .htaccess).
• If needed, use SSH remote execution capabilities to run commands on the server to do tasks like setting special permissions (for example, write permissions on Wordpress upload directories).
• Give me a nice "deployment successful" message :)

That's it, once the script is in place deployment becomes fun. Run a script, go the the live server to see everything works, done.

Hope this helps.