How to use SVN to manage Web sites?

Question

We have a 4Gb data on our Web server.

We consider to use Subversion (SVN) in order to increase reliability and eliminate data loss both on our site (which is 4 Gb, mainly of images, Flash, and video) and on other sites we develop.

My idea to use SVN on our main site is the following:

• have a separate SVN repository for these files which we directly edit (such as .html files, .pl and .pm files, etc.)
• have a second SVN repository to store the entire 4 Gb dumps of our main site, as a sophisticated backup mean (with the ability to merge with later changes in the case of an error recovery).
• have more SVN repos for other sites we develop.

I ask:

• is SVN fast and scalable enough for that 4 Gb versions? How much time a commit would take?
• Is it a good idea to have two separate repos on our site, for all data and just for the code?
• Could you provide us with a (maybe Bash or Perl) script which would help us to update our server's httpdocs/ on request?
• What's about having two Web servers, one running the HEAD for debug and other a stable branch for the outside Internet?
• How to easily manage several SVN repositories for several sites we host on our server? (any tips?)
• How to manage database (MySQL) backups with SVN?

Added: We don't need to store deltas of binary files. Most often binary files on our sever just don't change. But we need a fast mean to figure if a binary files changed.

Answer 1

Subversion is not a replacement or not a competitor for regular backups and backup strategy!!!

You have to use every tool in The Right Way (tm)!

Answer 2

SVN excels at source code control (which is what it was designed to do). The same goes for any source code control system, the more non-source code you ask it to manage, the lower satisfaction you can expect.

Maven repositories excels at binary code management (which is what it was designed to do). You can basically check in any particular file (with minimal "maven project structure") and Maven can then offer it to satisfy "dependencies" that other projects might have.

Perhaps a SVN checked-in Maven project for the source code (aka HTML / Javascript / CSS / etc) stuff, and dependencies within the Maven project for the binaries (Images, Videos, PDFs, etc)? Then you would have a deployment process that looks like:

1. Checkout to a build location, (svn checkout)
2. Build the website (mvn install, which will suck down the dependent binarires)
3. Package the website (mvn package probably to a zip file, or tar.gz).
4. (later) Deploy the website (mvn deploy probably to different locations depending on active profile (production, development))

Whatever you do, avoid the following anti-patterns, they will cause you more grief than you expect:

1. Don't checkout directly to the web server to deploy.
2. Don't skip the packaging of the website, or else it will become difficult / impossible to roll back (or even assure full deployment).
3. Don't expect to develop the web site in a live directory. Get used to developing the site, building it, deploying it locally (Maven can make this easy), and then checking in your changes (if it looks good).

Attempt to rework your site to allow deployment to any machine / directory location, facilitating "bringing the site up" in verification servers / locations prior to going live. Maven provides "profiles" that can help in separating the live site and a generic developer site. Just remember to aviod the Maven site target because that's not the product you are developing, that's the management product for tracking the progress / quality of the product (your developed website).

Eventually with SVN / Maven, you could work in a Jenkins server to do the "mainline" builds for you. Later you could add Selenium servers for automated integration testing, and utilize Continuous Deployment practices, but one small step at a time. Choosing this path isn't bad, but unless you already have some familiarity with the tools, odds are you have a bit to learn.