Tuesday, October 31, 2006

Subversion and Apache

So, yesterday I came into the office with a pleasant surprise.

One of my coworkers turns around and says: "We have Apache up and running. Goto this URL and check this out."

And it's our Subversion repository over http, on Firefox, on a webpage!

When we started our process, we hadn't thought much about it. We initially went with the default svnserve option available in the 1.4 release - it worked out of the box with little to no configuration. The only problems there were the user authentication. By default Subversion authenticates against a file with a pretty simple scheme:

user1 = password1
user2 = password2

Not the most secure option, to be sure. We had talked about getting Apache up and running on the server we were hosting the repository on, but it was something that I thought we might tackle sometime this week. This guy spent his weekend installing and configuring Apache to work with our repository.

He used a couple of existing resources, and we only had to iron out a couple things to get it working right. I'll point these out here.

Here's our httpd.conf:


DAV svn
SVNPath x:/RepositoryPath/

# our user authentication policy
AuthName "SVN Server"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain DOMAIN
SSPIOfferBasic On
Require valid-user

AuthzSVNAccessFile "x:/PathToOtherConfFile/AccessFileName.conf"




A couple gotchas that we rant into: the SVNPath needs a trailing slash - we had some authentication problems without it. Also, make sure you have SSPIOfferBasic On set. Windows machines with logged in domain users shouldn't have to authenticate manually - it'll pass credentials along for you. Firefox can still browse the repository, it'll just need to authenticate manually. I believe TortoiseSVN users won't need this option, but it's good to have in case you ever need to authenticate using any other client (such as the command-line version).

AuthzSVNAccessFile looks something similar to this


[groups]
developers=DOMAIN\user1, DOMAIN\user2
managers=DOMAIN\bossman

[/]
developers=rw
managers=r


Basically, you have groups of users that you can define, then their repository permissions. The example above gives the developers group read/write permissions to the entire repository ("/") while managers can only read.

You could do some more complicated things, like secure certain projects in the repository. The important thing to remeber is to have the usernames with the domain in all caps, followed by the username it it's correct case. The username passed into the DAV module will be checked against here first, then passed on to the domain controller, and it's case sensitive here.

Also, when you install Apache, it'll give you two options - install as service (Everyone) monitoring port 80, or not as a service, run from the command line (Just Me) and monitoring at port 8080. If you're using IIS, then you'll want to choose the second option. You can reconfigure the port, of course - it's in the httpd.conf file. Just find the part that has


Listen 8080


and change it to whichever you want.

When you finally get it configured correctly, you'll probably want to install Apache as a service. It's simple - just type



apache -k install -n "MyServiceName"


in the console. (Change "MyServiceName" to something else, unless that's what you really want it to show up as. It'll install itself in the Apache service monitor and the Windows Services menu.

One final caveat - you have to use Apache 2.0, not 2.2. The Subversion modules don't load.
Also, install Apache before you install Subversion if you can - it'll make your life much easier. The Subversion installer will detect Apache and copy all the required modules over where they need to go. If you didn't (like us) then you'll have to do it manually.

You'll need mod_authz_svn.so and mod_dav_svn.so, which should be found in your Subversion\httpd directory. Copy them to the Apache\modules directory. Then, get libdb42.bin from Subversion\bin and copy to Apache\bin. I think this is everything - if I've gotten something wrong I'll update this as necessary.

My project today is to get https working on Apache - I'll post later on how that goes.

Sunday, October 29, 2006

Subversion and the Big Apple

Say you're working in a company with a top-notch creative department. They're excited about your new push for not using SourceSafe. Only one problem.

They're using Macs.

So, what do you do? You could tell them to use the command-line version and leave you alone. You could tell them to use Parallels and use the Windows pretty clients. Or, you could look for other options.

I'm not a Mac guy. Don't get me wrong, I think they make some great machines. The move to Intel processors has sorely tempted to get one for my home computer. My wife loves the Mini. But in a .NET world, Windows is the way to go. So, naturally, that's where I started looking for clients.

But your pretty pictures and shiny stylesheets (mmm... alliteration) don't have to come from a Windows machine. And if they don't, you still need a way to get them from your creative types to your developers.

We're evaluating both options right now. svnX is free, ZigVersion isn't. I'll let you know what our design team thinks.

One more thing. There's a lot of Java Swing based clients out there. We didn't like them for the same reason some people don't like Swing applications - it just doesn't feel right. It's not quite Windows, not quite OS X. That's just a personal preference.

Saturday, October 28, 2006

The Subversion Conversion

If you've ever looked for a blog on software development, you've undoubtedly stopped off at Joel Spolsky's little corner of the inter-web. And if you have, then you've probably read The Joel Test. That first item on it - "Do you use source control?" is something I'd like to talk about over the next few weeks.

If you use Visual Studio, you've at least heard of SourceSafe. Heck, you've probably used it, or are using it right now. Would everyone reading please raise their hand if they really, really like SourceSafe? Do you feel warm and fuzzy inside knowing your code is "protected" inside of SourceSafe? Anyone?

No? Me either.

So, what do you do? You can either live with it (not a good idea) or you can change it. Now, in an ideal world, you'd be able to either convince your boss/CFO/purchasing department to whip out the credit card and buy everyone Team System. Try it. If they react the same way most would (and to be fair, it is approximately 1 hojillion dollars per developer) then you've got to find something cheaper. Or, dare we hope, free.

Enter Subversion. It's open-source and free-as-in-speech, and best of all, some of the CVS developers that got tired of it work on Subversion. So you know they've got some background on the subject.

"But Nic", I hear you say, "isn't getting this running for a group of developers who are familiar with SourceSafe and doing things Their Way going to be a pain?"

Yes, probably. But, instead of dealing with quirks and worrying about database corruption and that offsite developer whining about how slow it is, my company decided to take a more pro-active approach. I'm a firm believer in Getting Things Done. And if I have to "deal" with my source control system, I'm not Getting Things Done.

So, go ahead and download the latest copy for your environment from here. And if you're using Windows, and if someone tells you that you must have Apache installed before you can use Subversion, they are either a LIAR, or simply confused. You only need Apache if you're going to be doing http/https-based access or want to do some fancy authentication (like Windows Domain). For testing on your local machine, you don't need it.

If you're a Windows user, definitely get TortoiseSVN. It's a Explorer Shell Extension that encapsulates just about everything you'd do with the command-line version into that pretty GUI that we Windows users need. If you're using Visual Studio, then you should also pick up AnkhSVN. It's a plug-in that will enable SVN commits/updates from within Visual Studio, and it knows not to check in your compiled DLL's, or the SUO files.

From my testing, I've found it best if you have all of the projects within a solution in the same working directory. This will probably not be the way that Visual Studio is doing things for you - it defaults to putting ASP.NET websites in one directory, and everything else in another. For both Subversion's sake, and your own, keep everything in the same directory. Cassini can run a website wherever you put it. If you're still building .NET 1.1 websites, you can also setup IIS to have a website wherever your working directory is, and the applications should get created automatically when you pull them down, or when you create new ones. I'm still experimenting with this, so please leave me some feedback if you have any insight on this.

If you're serious about taking this plunge, then I highly recommend you first go pick up Pragmatic Version Control: Using Subversion. It's short, and has a great overview of what someone who likes to Get Things Done should be doing with their source control system. It says version 1.3 on the cover, and 1.4 is the latest version as of this post. Nothing significant from a user's perspective has really changed, it's a lot of internal improvements, API changes, and some administrative enhancements.

Now, as far as a company-wide conversion, we haven't taken that plunge yet. But, we will. We need to figure out some best practices, repository structure/locations, and the general process first. So, stay tuned. We're in this together.

Obligatory Introductory Posting-y

Here's my first blog post. I'm supposed to use this to space to introduce myself and why I'm blogging, and why you should care.

I have a beautiful wife named Veronica. We've been married for about 10 months now, and we have two great dogs named Punkin and Dany. I imagine you'll all be able to see pictures and hear all about them. Those three ladies are what I come home to every day - they're very important to me.

I have a degree in Mathematics from the University of North Texas that I obtained after 6.5 years of grueling, diligent studies (at least, that's how I like to think about it.)

I recently got a new job working at Ariamedia in Addison, Texas. I'm their newest developer there. I'll probably spend a lot of time talking about some of my experiences there.

I have a lot of great friends, some that even have blogs of their own.

My name is Nic (no 'k') Webb. My middle name starts with 'C' and depending on whether you ask the Texas Department of Transportation or the Social Security office, the rest of it is either "ameron" or "ahill." It's an interesting story, which I'll elaborate on in a future posting.

I believe that a person's life is a series of experiences, and I like to savor each one. Too often I've found myself waiting for "the big payoff" in life, and I've come to discover that the payoff is the journey.

I hope you'll enjoy these snapshots of my journey.