The following steps outline how to install and configure Subversion v1.4.

1. Download the latest subversion package from here (Described as "Windows installer with the basic win32 binaries").

2. Using svnadmin (In the Subversion bin folder) create a new repository: svnadmin create drive:\my\repository\path

3. Setup the Subversion server as a windows service as specified here. If you want to store repositories on drives other than the drive the subversion service is running on or you would like access to be restricted to a certain path you will need to specify a repository root. This can be specified in the service setup.

4. Configure security as specified here.

5. Install a Subversion client such as TortuousSVN and test access to the repository: svn://MyServer/MyRepo

I want to start off by saying that I am running subserve v1.4 as a Windows service. From what I have read configuration may be somewhat different when using httpd, SSH or on another OS. So the following may or may not fully apply to other access methods, versions or OS’s.

svnserve.conf

The first repository security configuration file you will encounter is the svnserve.conf file. It appears that Subversion looks for this file specifically under the “conf” folder within the repository tree. I don’t believe there is a way to configure this path or the filename it looks for. This file has only one section called “general”. It contains 5 basic security settings. The settings are as follows:

anon-access: Valid values for this setting are read, write or none. This value specifies repository wide access for anonymous users. If there is a conflict with this setting and with folder permissions specified in the authz file, the most restrictive permission is applied.

auth-access: Valid values for this setting are read, write or none. This value specifies repository wide access for authenticated users. If there is a conflict with this setting and with folder permissions specified in the authz file, the most restrictive permission is applied.

password-db: This specifies a path to a user database. This can be an absolute path (“C:\config\passwd”) or a relative path (“..\..\config\passwd”). If no path is specified only anonymous access will be supported. Only the anon-access permission will be in force.

authz-db: This specifies a path to a folder permissions database. This can be an absolute path (“C:\config\authz”) or a relative path (“..\..\config\authz”). If no path is specified then path based permissions are not applied. Only the anon-access and auth-access permissions will be in force.

realm: This is a string that serves as a unique identifier which identifies a realm or security domain the repository is associated with. A realm is basically the user base contained in the user database (passwd file). Each repository that shares a single user database should have the same realm specified. So for example if you had a user database at “C:\config\passwd” which was used by three repositories, all three repositories should have the same realm specified.

passwd

The second file you will encounter is the user database. The name of this file is passwd by default but can be anything. If user authentication is desired the path to this file must be set in the password-db setting in the svnserve.conf file. If no path is set for this setting, no user authentication will take place. The user database can be shared by multiple repositories. Each repository that shares a single user database should have the same realm specified. The user database contains only one section called “users”. The settings in this group are username/password pairs. For example:

[users]
bsimpson = R@dio@ctiveM@n
lsimpson = Bl33dingGumsMurphy
mburns=Smith3rs
djquimby=V0t3Quimby

authz

The third file you will encounter is the path based permissions database. The name of this file is authz by default but can be anything. If path based permissions are desired the path to this file must be set in the authz-db setting in the svnserve.conf file. This file defines user groups and path permissions. The first section in this file is called “groups”. Here you can specify groups and their membership. Each setting is a group name and a comma separated user list. It does not appear that white space in this list causes any problems. Unfortunately as of  Subversion 1.4 you cannot specify user groups in the user database (passwd), only in this file. Here is an example of the “groups” section:

[groups]
admin = mburns, djquimby
users =  bsimpson, lsimpson

The sections that follow are path specific permissions. The section name is the path. The path begins with a forward slash but must not end with one. Evidently (As of Subversion 1.4) the “repository” prefix for repository specific permissions (IE: [repository:/yada/yada]) is ignored when using svnserve to access repositories. It appears that it is only recognized when using the httpd access method. So separate files would have to be maintained to provide repository specific folder permissions. Otherwise if identical paths existed in two or more repositories the permissions for those paths would be identical, there would be no way to differentiate them. Each path permission section contains members which could be a group name prefixed with an ampersand (@), wildcard (*) denoting all users (Including anonymous) or simply a username. The permissions are ‘r’ for readonly, ‘rw’ for read/write or ‘’ (Blank) for no access (Including anonymous users). Permissions are inherited from the parent folder if no permissions are specified for a particular path. If permissions conflict, the least restrictive permissions are applied. Here is an example of path permissions:

[/common]
* = rw

[/config/admin]
@admin=rw
lsimpson=r

[/docs]
@users=rw
@admin=rw

[/secure]
@admin=r
@users=

I am running svnserve as a windows service on our build server. I thought it was pretty cool that you could point repositories to central security configuration files. This is really nice if you have multiple repositories, only two files to maintain for each relm. Problem is though that when you set a repository specific folder permission ([repository:/yada]) in the authz file it is totally ignored. For example:

[repository:/reporoot/repo1]
@group1=rw

[repository:/reporoot/repo2]
@group2=rw

This does nothing! I did a little searching on "the google" and evidently the repository specific prefix only works with httpd access. For svnserve access you have to specify an authz file for each repository to specify repository specific permissions. Posts here and here discuss this issue.

Many times when we think of OSS we think "cost savings" or “free”... Not so. There are many hidden costs that accompany the integration of OSS into your infrastructure. I’m currently in the process of integrating some OSS into our infrastructure and am really seeing this. Now don’t get me wrong I’m a big fan (and user) of OSS but it’s important to see the big picture when making decisions and planning projects that involve OSS.

One of the hidden costs is learning and configuring. OSS, from what I have seen, seems to be seriously lacking when it comes to ease of use and configurability. Many times OSS is command line based, configuration is in INI style config files. It takes time to read through documentation (Which may be sparse in some cases). I have also found that actually playing around with the app and configuration is in some cases the best way to figure out how to configure and use the software. Again, all of this takes time. On the other hand the pretty app that you pay for will (If it’s any good) have an intelligent installer, very intuitive GUI, and lots of support and documentation. I recently had an experience where I setup one of those “pretty, paid for” apps and I literally had it up and running and configured in a couple of hours. I was totally blown away! If it were OSS it would more than likely taken me a couple of days (Or more) to get in there and figure it out.

Another hidden cost I have seen is maintenance… Many OSS software packages have cryptic or crud management and/or maintenance interfaces. These can be cumbersome and time consuming to work with and can be difficult to get others up to speed on using them. This may also lead to neglect because it’s a pain to work with or others don’t feel they have the time to learn it. The app that you pay for (If it’s any good) will probably have a slick interface to maintain and administer.

Again, I’m not knocking OSS, I think OS development is a wonderful thing. There are a lot of awesome OS projects out there. I also think that OSS fills an important roll in any infrastructure. But when you decide to go the OSS route you can’t be in the mindset that because it’s OS it’s free. You really have to think about the pros and cons and make a decision based on that. In some cases it may actually be cheaper (And more advantageous) to buy instead of going the OSS route.

As a side note, I have heard some balk at “pretty, paid for” apps for various reasons, some valid some not objective at all. But the reality is this: Those days as a single guy staying up all night eating Doritos, drinking Mt Dew and hacking on all kinds of interesting stuff are over. In the real world you have a family, deadlines and clients (both internal and external). Time is really of the essence and you dont have much of it. Your boss or your wife and kids aren’t going to be impressed because you worked OT for 2 weeks learning how to wiz around some cryptic OSS like Kevin Mitnick phreaking a telco switch. The time spent getting to that point may not be worth it or you may not even have it. In many cases “pretty, paid for” equate to steep learning curve, ease of use and maintenance and good support. They also may mean less stress and more time for life’s more important things. It really comes down to making a good business decision that will help your business to succeed, not a decision based on ego that makes you think your The Brain.

I ran into an issue where I could not enable the VMRC in MS Virtual Server 2005. I would check the box and save the settings but it would revert right back to being disabled. Turns out that VNC server happens to run on the same port, 5900, as the VMRC. So if you are running VNC you have to change the port for either VNC or VMRC. I wish the control panel would have just thrown an error but it's those sort of things that keep life interesting...

Previously (Prior to v1.4) the Subversion server (svnserve.exe) couldn’t be natively run as a Windows service. You had to use a wrapper such as srvany.exe from the Windows res kit to host it. Well now as of v1.4 it will run as a service but you have to manually install it. Doing this is pretty simple; just use the sc utility to add it at the command line as follows. The first svnserve switch (--service) notifies it that it should communicate with the SCM. The second (-r), which is optional, allows you to specify the root repository path.

C:\>sc create SubversionServer binpath= "\"C:\Program Files\Subversion\bin\svnserve.exe\" --service -r  e:\Subversion\RootRepo" displayname= "Subversion Server" depend= Tcpip start= auto

C:\>sc start SubversionServer

You can find the release notes about this new feature here.

So I needed to setup build, dev and staging servers on a limited budget. Getting 3 new servers in a small company is not always feasible as you probably already know. The solution? Microsoft Virtual Server 2005. Although I was familiar with the concept of running virtual servers I had not actually done it before (Shame on me!). So I was very surprised with just how easy it was to setup and configure MSVS! The configuration is so intuitive that I literally didn’t read a word of documentation (Which really appealed to my male, "I don’t need to read the directions" side… ) and had a virtual server up and running in no time. The other thing that really surprised me was performance. I’m running Windows Server 2003 Standard on a 2.0 GHz AMD Athlon XP 2400+ box with 1 GB of memory (Not a very beefy box). The host system is acting as the build server and two virtual servers are running as a development and staging servers (Both running Svr 2003). I’m very surprised how "zippy" the virtual instances run.

Our network admin had a great suggestion; first create a template server which can be copied for new instances. That way you can create new instances with out having to start from scratch. When you create the new instance you need to give Windows a unique SID. Sysinternals has a free SID changer tool called NewSID which will do this. You can then take it a step further and create instance specific copies. For example I can get our dev and staging server’s setup exactly how I want them and make a copy of those instances. Then if either one of those servers gets hosed I can wax them and copy out a fresh version literally within a few minutes.

MSVS installs a net driver that allows all instances to share a single NIC. From what I have read, each instance is assigned a random MAC address. The NIC is put into promiscuous mode and packets are filtered and routed to the virtual servers.

All in all I'm very impressed with MSVS. And I'm pretty hyped about how easy it is to setup complex test and R&D environments with minimal hardware. I would be curious to see how it compares with VMWare. I guess I'll save that for another weekend...

Microsoft offers Virtual Server 2005 as a free download here.