Learning is an Art

Here I am going to talk about three useful and handy subcommands  of svnadmin that will help us in dumping our data and restoring it back to fresh repository, restore is very critical, as we keep on backing up data but we seldom bother about restoring it to check if everything is working fine or not. I would like to put one point across that your backup is as good as your last restore.

Dumping the repository

This is the simplest option for dumping the repository for purpose of backing up your repository. If you want to do an incremental back than you need to specify –incremental flag and give start and end revision for same.

Restoring the repository back

Verify the restore

Habit of restoring the data regularly is very important for having usable backup.

This article covers how to setup domain authentication for Subversion with Apache using mod_auth_sspi , I am running Apache 2.2 and Subversion 1.5. First of all you need to get SSPI module from its new home at sourceforge , module can be directly downloaded from here. Once you have downloaded the module extract using some zip utility there will be a bin folder inside the extracted folder and inside bin folder there will a file named mod_auth_sspi.so take this file and drop it in Apache’s modules folder.

Once you are done with above steps we now need to modify Apache’s httpd.conf to include the domain authentication for our Subversion repository make changes to httpd.conf as shown below,  first we need to ensure that we have required modules loaded

To mod_dav_svn to work you need to uncomment the line which loads mod_dav module Apache look for it and uncomment if its commented.

Now the real magic configuration starts which will enable us to authenticate Subversion users against AD domains make changes in httpd.conf as shown below

Once done with above changes save the file and restart Apache and try accessing the URL http://<yourservername>/svn/myrepo you will be prompted for authentication saying “Subversion Domain” enter your domain name without domain as we have SSPIOmitDomain On and based on Subversion authorization file i.e authz in our scenario you will be able to see repository or you will get forbidden error.

We are done with setting up domain authentication, in-case you face any problem with above settings feel free to write to me.

LoadModule sspi_auth_module   modules/mod_auth_sspi.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

Assuming svn keywords property is enabled on your office files you need add the keywords in the syntax shown below

The noticeable difference from the keywords expansion in text file is the extra spaces given after :: if you don’t give extra spaces than your file will get corrupted as during expansion the space required for expansion will not be available and hence causing corruption of files.

Subversion 1.5 is out and its been almost half year to it. Now thought comes to mind where to go from here, Subversion has still a long way to go from here, Subversion developers should not content with accomplishments in 1.5 its still a long way for Subversion to go to be an enterprise software, having said that I would also like to point that penetration of Subversion in enterprise environment has considerably increased but still it has an uphill task and I am sure that Subversion development team is aware of same.

I am big fan of Subversion thats why I sometime ponder about its future, when I see fanatics talking about GIT, Clearcase and Perforce. I was really saddened when Linus trovalds in his speech said “whole point the Subversion project started is wrong” but I have not found anything wrong with the tool, may be I am not as capable as Linus and neither I am into kernel development but Subversion works pretty well for me and so does for my organization, and there are many other Subversion works for them too.

There is a big wish list which people might have for Subversion but I would say to Subversion developer community add the features which are good for tool as whole and keep in mind that Subversion is version control first anything else later.

What is WebDAV

WebDAV stands for “Web-based Distributed Authoring and Versioning”. It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers. The tragedy, though, is that despite the acronym, the RFC specification doesn’t actually describe any sort of version control. Basic WebDAV clients and servers assume only one version of each file or directory exists, and can be repeatedly overwritten.

It was only few years, later RFC 3253 added versioning concepts to WebDAV, placing ‘V’ back in DAV, hence the term DeltaV. WebDAV/DeltaV clients and servers are often called just “DeltaV” programs, since DeltaV implies the existence of basic WebDAV.

Original WebDAV standard has been widely successful. Every modern computer operating system has a general WebDAV client built-in, and a number of popular standalone applications are also able to speak WebDAV — Microsoft Office, Dreamweaver, and Photoshop to name a few. On the server end, the Apache webserver has been able to provide WebDAV services since 1998 and is considered the de-facto open-source standard. There are several other commercial WebDAV servers available, including Microsoft’s own IIS.

DeltaV has not been so successful; it’s very difficult to find any DeltaV clients or servers. The few that do exist are relatively unknown commercial products.

Subversion client is not a fully-implemented DeltaV client. It needs certain types of things from the server that DeltaV itself cannot provide, and thus is largely dependent on a number of Subversion-specific HTTP REPORT requests that only mod_dav_svn understands. And also mod_dav_svn is not a fully-realized DeltaV server. Many portions of the DeltaV specification were irrelevant to Subversion, and thus left unimplemented.

Autoversioning

Though Subversion is neither a full DeltaV client nor the Subversion server a full DeltaV server, there is silver lining known as Autoversioning.
Autoversioning is an optional feature which is defined in the DeltaV standard. A typical DeltaV server will reject a WebDAV client attempting to do PUT to a file that’s under version control. To change a version-controlled file, the server expects a series proper versioning requests: something like MKACTIVITY,CHECKOUT, PUT, CHECKIN. But if the DeltaV server supports Autoversioning, then write-requests from basic WebDAV clients are accepted. The server behaves as if the client had issued the proper series of versioning requests, performing a commit under the hood. In other words, it allows a DeltaV server to interoperate with ordinary WebDAV clients that don’t understand versioning.

To activate autoversioning, you will need to add directive known as SVNAutoversioning in Apache httpd.conf file and set it as on.

When SVNAutoversioning is on, all write request to from WebDAV clients result in automatic commits. A generic log message is auto-generated and attached to each revision.

For reference on how to set up Subversion repository as network share drive using Windows Web-folders please read Using Subversion Repository as WebShare.

References:

• Subversion Documentation
• http://www.webdav.org/

This article assumes that you have installed and running Apache Server 2.0.59 and Apache is hosting your Subversion 1.4.4 repositories on windows XP machine. Might work with other versions and other Operating Systems also but same is not tested as far as I am concerned.

Step1: Changes in Apache httpd.conf

Add SVNAutoversioning directive in your Apache’s configuration file as shown below, which can be found in conf directory Apache installation.

When SVNAutoversioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is auto-generated and attached to each revision. Before activating this feature, however, understand what you’re getting into. WebDAV clients tend to do many write requests, resulting in a huge number of automatically committed revisions. For example, when saving data, many clients will do a

of a 0-byte file (as a way of reserving a name) followed by another

with the real file data. The single file-write results in two separate commits. Also consider that many applications auto-save every few minutes, resulting in even more commits.

If you have a post-commit hook program that sends email or generates RSS feeds, you may want to disable email and feed generation either altogether, or on certain sections of the repository.

<Location /repos>

DAV svn

SVNPath /path/to/repository

SVNAutoversioning on

ModMimeUsePathInfo on

</Location>

ModMimeUsePathInfo allows

which is Apache’s module to attempt automatic deduction of the mime-type on new files that enter the repository via autoversioning. The module looks at the file’s named extension and possibly the contents as well; if the file matches some common patterns, then the the file’s

property will be set automatically. For this you will have to uncomment or add the load module directive for mod_mime.

LoadModule mime_module modules/mod_mime.so

Make sure that this line is present in load module section of httpd.conf and uncommented.

Now your Apache is set to accept DeltaV or WebDAV Clients.

Step2: Creating Network Share

Create network share i.e. a web share on some client machine or you can do it on same machine.

Go to My Network places -> add network place

You will see add a network place wizard click on next, than you will ask where you want to create this network place click next.

You will see a window as shown below asking you to enter Internet or network address

Enter http path to your repository, please don’t forget to add port number to it. e.g. http://myserver/repos and click next than you will be asked for authentication enter your credentials for repository access and than it will ask you the name of your network share enter any name you want.

Your repository is mounted as network or Web Share.

Now you can edit your files and cross check your repositories log messages to see auto commits and auto generated log messages. Which say’s commit by a non DeltaV client.

But before really using it you should make sure that you should know what you are doing. As far as I see this can be of great help to people who are non-developer and want to manage documentations with customers and among there team with actually needing a Subversion client lie Tortoise, many people think it’s a killer feature and I am no exception to it but the bottom line is that it comes at cost and you should know what the cost is and you are willing to pay it.

There has been a lot of fuss about which is the better version control system among the likes of CVS, Subversion, Git, SVK, Perforce, Accurev, the list goes on and on. But I am going to limit myself to Git and Subversion which are frequently being compared in the arena of SCM. These two version control systems fall in two different categories

• Distributed version control systems like Git and Code Co-Op
• Centralized version control systems like CVS and SVN

Distributed Version Control system

• In a distributed version control system every developer has his own private copy of the complete source code on his or her machine.
• They can put changes in their modules and can sync their changes with other developers.
• If by any means, access to the developer’s machine with whom you generally sync is not available, you have options to sync it with others. Also there is no bottleneck as you can sync with anyone in your project.
• This system is generally structured as a pyramid, as developers at a particular level can deliver changes with other developers on their level or the level above them and at the top of the pyramid is the person who holds the decision of what actually goes in the main line of development.
• Developers can work on the source code their own way without affecting anyone else. These developers can work with their fellow developers and sync changes with each other.
• Each can decide what changes to accept or reject from their fellow developers.
• The advantage is that the code is distributed and there is no “point of failure”.
• Distributed systems enable a lot of private work in a way that is bad for the development.
• Maintenance tends to be sloppier on distributed systems.
• Git falls in this category; this type of development is not used very commonly. Perhaps the biggest example of this is Linux kernel development.

Centralized Version Control system

• In a centralized system there is a repository on the central server where all the source code goes.
• Every developer checks out the working copy of the same piece of code and then makes changes in their working copy and everyone can commit changes to the main line of development.
• Anybody can put changes in anyone’s module if no folder level control is exercised.
• In such a system every one gets the changes of other developers whether they are willing to do so or not. A centralized system is much more likely to be backed up and its hardware kept up to date.
• Subversion falls in this category. This type of development is very common. Sourceforge.net follows this type of version control.

The distributed systems do work by not needing a server (except for rsync and any web server). But truly speaking the server-less system they set up is more complicated in actual practice than a single well-maintained server.

The official claim is that a centralized server cannot handle distributed type of development. I disagree that centralized servers cannot handle this development methodology. Let’s imagine a centralized version control system that has excellent branch development capabilities. No developer directly works off the trunk. Instead, each developer has one branch that is created from the trunk. Developers can merge their branches into the trunk or in other branches as done in distributed systems. For this to work, branching and merging operations must be smooth. And even the pyramid structure of distributed system can be implemented by controlling which all branches are to be merged in the trunk.

Subversion can be better but this has nothing to do with centralization. With the benefits of a centralized system, Subversion also gives you the flexibility to be used as a distributed system if you use right approach to it.

This is my personal opinion based upon my experiences working in the software engineering field. Feel free to comment on it and point out errors in judgment, if any.

It’s been long time and we keep hearing a lot about Subversion 1.5. I am a bit curious and tempted to see what actually it has to offer us.
I went through all the stuff on the Collabnet website and tried all the stuff there, even the available binaries of Subversion 1.5 and Eclipse GUI client for same. Don’t worry, I am not going to discuss advance merging and tracking and all, I will just give you a walk through of what all features it has in store for you. I wanted to write this document because I was looking for a document which is short and sweet and gives me crispy details, of what all things are about to come, though I didn’t find one but I hope that this will the end of your search for such a document, provided you are searching for something like that. I will discuss a few of the key features which will be available in Subversion 1.5.

Merge Tracking: We all needed it desperately and it’s going to be out in some time. Presently Subversion offers branching and merging but does not record them in history. Subversion 1.5 will give auto merging facility and manual merging facility and will maintain its history which change sets were merged and when they were merged, so now it‘s not required to remember the merges performed. SVN command blame and log will also give the details of merges in history. The presently available client on collabnet is for Eclipse and it offers two types of merges: Standard merge based on URL and revision inputs and advanced merge (exposes all command line options). You will not get the installer for it; you can automatically install it through the update/install option available in eclipse menu.

Sparse Directory checkouts: This is also one of the much needed additions. Presently in Subversion when you check out a directory you get all the directories below it in your working copy whether you need it or not. You have the option of only checking out top level folder, which is not enough. This becomes a messy business in large projects. Now with Subversion 1.5 you can check out selected subdirectories by specifying depth. Something like giving _depth = files.

Backing up FSFS repositories Subversion 1.5 way: This is a nice little feature added that will help make administration of FSFS repositories a little bit easier, especially when it comes to backup. The new feature is that `svnadmin recover` has now something to do for FSFS repositories. Most of you might not have come across it. It is one of those little features that were invented for the Berkeley DB repositories.

Tree Structured FSFS repository: This might not be of much interest to many but its there for you. Presently we have revisions stored in a single directory as db\revs\0 for revision zero and so on and so forth for revprops. This can lead to a single directory with large number of files. People relate some speed issues with it which I cannot understand. If you get it, do let me know. In Subversion 1.5, the structure has changed slightly. Newly-created FSFS repositories will instead use a two-level tree with up to (by default) 1000 files per directory. This means that revisions 0-999 will be stored in a directory db/revs/0/, revisions 1000-1999 will be stored in db/revs/1/, and so on.

Copy/Move improvements: Presently available move and copy is not true move; it is a two step procedure – first the deletion of old files and then the addition of new ones. In Subversion 1.5 we can expect a true copy and move or even rename.

There are few more features, but I am not going to discuss them here. The above mentioned ones are what I thought might interest people.