Learning is an Art

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.

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.