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.
What’s in it for ME?
As often as I change the scripts I use and modify the web pages I (have) design(ed), I think I have finally realized that I need to 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. If only I knew how to set this up little over a year ago, I would have certainly used it to keep track of my dissertation writing process [and not forgotten, by complete accident, to thank a bunch of my beloved seniors from M.Sc. days in Bangalore University].
It’s my practice to do a full/maximum installation of the OS and as such, that will ensure that most packages – though not everything needed – will be present, whether I use them or not. As such, I had Apache & Subversion up and running but was missing the mod_dav_svn module. One way to figure out its presence/absence is to look for /etc/httpd/conf.d/subversion.conf. If the file is there, then there is a good chance that the module is already installed. If the file is not there, then there is a very good chance that the module is missing. Either way, running the following command as root will ensure that the module (as well as subversion itself) will be installed, if not already installed.
yum -y install subversion mod_dav_svn
Updating httpd.conf and subversion.conf
Before updating these config files, one needs to create some directories. As root, I did:
1 2 3 4 5
mkdir /var/www/mydomain.svn mkdir /var/www/svn cd /var/www/svn svnadmin create repo chmod -R apache:apache repo
In my particular case, I have several VirtualHosts configured in httpd.conf and as such, I did not edit /etc/httpd/conf.d/subversion.conf. I took the information from there and added it appropriately in /etc/httpd/conf/httpd.conf.
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
<VirtualHost *:80> DocumentRoot /var/www/mydomain_svn ServerName svn.mydomain.com ServerSignature On DirectoryIndex index.php index.html AccessFileName .htaccess ## Main Directory <Directory "/var/www/mydomain_svn"> Options Indexes FollowSymLinks Includes AuthName "Reserved for SVN Admin Only!" AuthType Basic AuthUserFile /var/www/mydomain_svn/.htpasswd AuthGroupFile /dev/null require valid-user require user svnuserid AllowOverride All Order allow,deny Allow from all </Directory> ## Value of SVNPath must not be under DocumentRoot ## defined above. Else, 'moved permanently' kind of errors ## are to be expected. # ## Also, creating .htpasswd file with an appropriate entry ## can be accomplished by referring to one of the many good ## online resources. <Location /> DAV svn SVNPath /var/www/svn </Location> </VirtualHost>
Once these changes are saved, Apache needs to be restarted.
Is it working alright?
Point the browser to http://svn.mydomain.com/ and if the browser presents a screen that looks like:
it should be working.
These can be found in Wikipedia as well as other websites, but I am including them here for my sake and for completeness purposes (Image courtesy: Wikipedia).
The Subversion filesystem can be described as “three dimensional”. In addition to the two dimensions of a standard directory tree (e.g., tree view), the Subversion filesystem’s third dimension is revisions. Each revision in a Subversion filesystem has its own root, which is used to access contents at that revision. Files are stored as links to the most recent change; thus a Subversion repository is quite compact. The storage space used is proportional to the number of changes made, not to the number of revisions.
The Subversion filesystem uses transactions to keep changes atomic. A transaction is begun from a specified revision of the filesystem, not necessarily the latest. The transaction has its own root, on which changes are made. It is then either committed and becomes the latest revision, or is aborted. The transaction is actually a long-lived filesystem object; a client does not need to commit or abort a transaction itself, rather it can also begin a transaction, exit, and then can re-open the transaction and continue using it. Multiple clients can access the same transaction and work together on an atomic change.
Subversion offers two types of repository storage â€” FSFS and Berkeley DB. FSFS works faster on directories with a large number of files and takes less disk space, due to less logging. Subversion has some limitations with Berkeley DB usage leading to repository corruption and data loss when a program that accesses the database crashes or was terminated forcibly. When using Berkeley DB repository, the only way to use it safely is on the dedicated server and by a single server process running as one user, according to Version Control with Subversion. Existing tools for Berkeley DB repository recovery aren’t completely reliable, so frequent repository backups are needed. The FAQ Section says that FSFS file system is default for Subversion v1.1.x [my instance runs 1.1.4].
Adding a project to the repository
Personally, I prefer to create the folder with appropriately named sub-folders:
Suppose that the folder my-big-project has the above structure (located in $HOME) and once the trunk folder has all the required files/folders of a project, then the following command may be used to import them into the subversion repository:
cd $HOME svn import my-big-project http://svn.mydomain.com/my-big-project -m "Adding my-big-project to Subversion Repository"
The process should prompt for a password [remember entry in .htpasswd file]. Once successfully completed, one may delete the $HOME/my-big-project folder.
Checking Out, Editing/Updating and Checking In
Now that the subversion repository contains my-big-project, one [an authenticated user] can check it out, edit/update and check it back in. The commands are as follows:
1 2 3 4
# Checking out cd $HOME mkdir my-big-project svn co http://svn.mydomain.com/my-big-project my-big-project
1 2 3 4 5 6 7 8 9 10 11
# Editing cd $HOME cd my-big-project 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.
1 2 3 4
# Checking in cd $HOME cd my-big-project svn ci -m "Checking in first set of revisions: 2 cool features added"
One can refer to excellent online resources for commands that help perform adding/deleting files/folders, tagging and branching projects, and so on.
Is Subversion it or is there something better?
There probably is one – dear friend, Jon (@nuxi), tells me that GIT is better than SVN. For now, this seems to have got me a good start and as I find more time, I will look into GIT. If you find this useful and/or find bugs/mistakes and/or have other elegant methods of accomplishing the same thing, please do share them – readers, including me, will greatly appreciate it.