Subversion (SVN) is a version control system initiated in 2000 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS). Subversion is well-known in the open source community and is used on many open source projects.
Subversion was started in 2000 as an effort to write a free version control system which operated much like CVS but with fixed bugs and misfeatures in CVS. By 2001, Subversion was sufficiently developed to be capable of hosting its own source code. More information, including this above paragraphs, is here.
Why manage websites with Subversion?
As I mentioned in my previous post, I often find myself modifying the web pages I (have) design(ed). It’s only fair [to me] that I keep a better track of changes – rather just relying on taking screenshots [which I mostly forget] and/or adding comments to the files and keeping just one copy. Keeping track of revisions with Subversion also makes it [relatively] easier & less time consuming to revert back to a specific version of the website.
Getting started with SVN
Please refer to my previous post.
BETA and LIVE versions
The proposed concept/work-flow is to check out a working copy from the repository, make the necessary edits, check it back into the repository, update the BETA version [to see if everything works the way it should] and then [if everything in BETA version is working fine] update the LIVE version. A schematic representation looks like this:
To that effect, let us assume that /var/www/mydomain serves the live version (http://mydomain.com/) while /var/www/mydomain_beta serves the beta version (http://beta.mydomain.com/), and that these locations are already in existence. The Apache configuration file, /etc/httpd/conf/httpd.conf, needs to have the following in it [one can add more stuff]:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 | # Live version UseCanonicalName Off DocumentRoot /var/www/mydomain ServerName mydomain.com ServerSignature On DirectoryIndex index.html index.php index.cgi index.pl AccessFileName .htaccess # Main Directory <Directory "/var/www/mydomain"> AllowOverride All Order allow,deny Allow from all # Beta version - password protected UseCanonicalName Off DocumentRoot /var/www/mydomain_beta ServerName beta.mydomain.com ServerSignature On DirectoryIndex index.html index.php index.cgi index.pl AccessFileName .htaccess # Main Directory <Directory "/var/www/mydomain_beta"> AuthName "Reserved for developers only!" AuthType Basic AuthUserFile /var/www/mydomain_beta/.htpasswd AuthGroupFile /dev/null require valid-user AllowOverride All Order allow,deny Allow from all |
Once these changes are saved, Apache needs to be restarted.
1 | /etc/init.d/httpd restart |
Add the following lines to /var/www/mydomain/.htaccess, so that any request to view .svn folders will be directed to an error code/page.
1 2 | # Do not display .svn (Subversion) stuff RedirectMatch 403 /\.svn.*$ |
Adding website to the repository
If your case is like mine, then you would already have a live website running – and its contents need to be imported into the repository. In that case, it’s a good idea to have a full back up of the website – so that there is something to revert back to, if things were to go wrong in the process. The following was my work-flow:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | cd $HOME # Backing up the website - trailing slashes in 'rsync' are important mkdir -p backup/mydomain rsync -avH /var/www/mydomain/ $HOME/backup/mydomain/ mkdir svn_projects cd svn_projects mkdir mydomain cd mydomain mkdir branches tags trunk rsync -avH /var/www/mydomain/ $HOME/svn_projects/mydomain/trunk/ cd trunk # Decide which files and folders should be kept in the repository. # Third party software [for e.g. PixelPost, WordPress] can be removed. # Keep a snapshot of current version as v1.0 cd ../tags mkdir 1.0 rsync -avH $HOME/svn_projects/mydomain/trunk/ $HOME/svn_projects/mydomain/tags/1.0/ # Importing into the repository cd $HOME/svn_projects/ svn import mydomain http://svn.mydomain.com/mydomain -m "First import of mydomain into SVN" # |
Depending on the size & type of files, it will take a while to import the website into the repository. When all said and done, one should see something like:
Checking out BETA and LIVE versions
Since /var/www/mydomain.beta location is [most likely] empty, it doesn’t pose any problem and checking out a [trunk] version is pretty straightforward.
1 | svn co http://svn.mydomain.com/mydomain/trunk /var/www/mydomain_beta |
Depending again on the size and type of files, it will take a while to check everything out. However, since there is [most likely] some stuff already in the live location (/var/www/mydomain), check out process will complain:
svn: Failed to add file ‘foo.bar’: object of the same name already exists
One way to deal with this problem is remove everything from /var/www/mydomain, check out a copy from the repository and restore the files [not in the repository] from the full backup created earlier. If the website gets a lot of frequent visitors, it might be a good idea to schedule a specific time slot for this process and let the visitors know about it well in advance.
1 2 3 4 5 6 7 8 9 10 11 12 | # Stop any cron jobs that might be writing stuff into this location # Delete everything in live website cd /var/www/mydomain chmod -R 777 \rm -rf * # Check out a copy from the repository svn co http://svn.mydomain.com/mydomain/trunk /var/www/mydomain # Restore the files, not in repository, from the full backup rsync -avH $HOME/backup/mydomain/ /var/www/mydomain/ # |
Once that’s done, the beta and the live versions both contain the trunk [a.k.a. bleeding edge] version of the website.
Checking Out, Editing/Updating and Checking In Local/Working Copy
Personally, I prefer to keep the local/working copy on a different machine [Apple MacBook, which has subversion installed]. The command to check out is still the same.
1 2 3 | cd $HOME/Sites mkdir mydomain svn co http://svn.mydomain.com/mydomain mydomain |
The files $HOME/Sites/mydomain/trunk/ may be edited/updated with a text editor of choice [I use vi but one can also use Coda or other such application].
1 2 3 4 5 6 7 8 9 10 11 12 | # Editing cd $HOME/Sites/mydomain/trunk # This 'svn info' and 'svn up'are very useful - lets us know the revision number, etc. svn info svn up # # Edit/update files using preferred editor; I use vi # svn stat svn diff # This tells what's different between local copy and the one on the server. |
Once the edits are completed, it needs to be checked back into the repository.
1 2 3 | # Checking in cd $HOME/Sites/mydomain svn ci -m "Checking in first set of revisions: edited /index.html and /css/mystyle.css" |
One can refer to excellent online resources for commands that help perform adding/deleting files/folders, tagging and branching projects, and so on. Personally, I tag the main versions as YYYY.MM and not-so main yet important versions as YYYY.MM.DD. One of the advantages of such a tagging scheme is that – in the absence of a web/graphical viewing interface of the repository/logs – I can still learn, just by looking in tags, about different tagged versions.
1 2 3 4 5 6 7 | # Tagging cd $HOME/Sites/mydomain svn cp trunk/ tags/2009.03 svn ci -m "Tagging version 2009.03 - a routine monthly revision" svn cp trunk/ tags/2009.03.23 svn ci -m "Tagging version 2009.03.23 - significantly changed the layout and approach" |
BETA Testing & LIVE Deployment
Once the edits are completed and the changes have been properly checked back into the repository, Beta testing is relatively easier.
1 2 3 | # These commands are to be executed on the web server cd /var/www/mydomain_beta svn up |
This will promptly update /var/www/mydomain_beta with files/folders that were changed/edited. If things looks good in the browser, then the same command can be run for LIVE version as well.
1 2 3 | # These commands are to be executed on the web server cd /var/www/mydomain svn up |
If BETA testing didn’t yield the desired results, one can go back to Checking Out, Editing/Updating and Checking In Local/Working Copy section, fix those mistakes, check the code back into the repository and redo the BETA testing.