I like to re-use code between projects, whether for personal use or professionally, so I created an Apache 2.0 licensed code repository.  Right now I just have my application configuration build tools committed (which I'll post about later).

The project home page is: http://code.google.com/p/sneal/

The project SVN URL is: http://sneal.googlecode.com/svn/trunk/

I did a commit from my home PC tonight where I don't have CCTray installed.  I don't have it installed largely because I'm usually disconnected from work VPN and CCTray will just show up as a gray ball in my systray.

After committing my changes I felt pretty nervous because there were a lot of new files added to the project and I wasn't using VisualSVN which would normally make sure these get committed.  After checking my email and not seeing any commit mails from the SVN server - I got very nervous.  Did my commit go into a black hole?  Is SVN down, did the build server crap out, is email down?  Ah!

I finally figured out Outlook wasn't synchronizing my Checkins mail folder for whatever reason.  In a panic I went and installed CCTray, and found that my commit was just fine and SVN didn't send it into a black hole after all.

I didn't realize that working with a continuous integration server with almost instant feedback is so tightly integrated into everything I do development wise.  What really surprised me was how much I use commit emails.  I didn't like commit emails when I first started the practice (they were a manual affair then), but now that they get auto generated upon commit using CaptainHook and use the SVN commit description, I've grown to really like them.

Now I can sleep soundly knowing that my code is safe.

If you look at all OSS projects out there (the good one's anyway), they don't even check in their AssemblyInfo.cs files, as these are auto generated when you run a build and the version # is just an MSBuild or NAnt property.  CC.NET should track the version number in its local project state file and pass that into the build script, or the version should be deduced from source control meta data.  Here are some typical responses from developers why they like keep version numbers in a text file checked into source control:

1. But what if we need to do a local build which needs to be versioned with something besides 0.0.0.0?  Why on earth would you ever need to do that?  Local dev builds should never be official, thus should never be deployed.  The continuous integration server is the integration point, not your local desktop.
2. But I need to use a specific version because my assembly is strong name signed to a specific version and I want to hot swap a DLL for testing purposes (or something more sinister).  If you really, really want a local versioned build, override the script's version property, but really you should be using a binding redirect in your app.config.
3. What happens if the build server dies and we lose the state file?  That's why you label source control with the version # every build, which you can use to build a new state file on the new CC.NET server.
4. We don't label source control, so now what happens if the autobuild server dies? You do output versioned builds somewhere don't you?  Look at your last build and rebuild your state file.
5. But, but, but...  That's how I've always done it.  Why? Sure its nice to keep everything in source control, but in this case there's no need.  Really you should be using the meta data of your source control system to manage build version increments, not some text file in source control.

While your removing your version.txt from your source control system, consider switching to SVN while your at it. 

I finally figured out why I was having problems specifying sub-folders (other than trunk) in my ccnet.config SVN source control provider trunkUrl element.  After toying around with svn log (which is what CC.NET uses to find changes), I discovered it only worked on some of the folders in our repository.  As it turns out you must specify the folder ensuring you are respecting letter case.

This does not work: svn log http://mysvnserver/svn/gp/trunk/commons

This does work: svn log http://mysvnserver/svn/gp/trunk/Commons

Notice the upper case C on the second line.  I'm sure this is probably documented somewhere in the SVN docs, but I don't remember seeing it.  The other possibility is that Apache is causing the problem.  Perhaps on Monday I'll care enough to look at the docs.

Warning, this is a bit of a rant…

Today I was trying to add a new unit test project to one of our solutions through the Visual Studio VSS plugin.  Everything seemed fine until I realized I had named the project folder incorrectly.  I thought “no big deal” I’ll just rename the project folder, but of course there is no way to do this through Visual Studio, you have to remove the project, rename the folder through Explorer, then re-add the project.  But since this was already checked in I would need to go through the VSS client and rename the project folder.  That’s why I hate source control integration with Visual Studio, it doesn’t support all scenarios (especially renaming things correctly to preserve history) and it tends to add an extra layer of complexity.  In addition to renaming the folder I needed to edit the solution to point to the correct location.  The one problem was that I forgot to change the stupid source control bindings so when you went to open the solution it wouldn’t find the project.  Apparently I needed to “rebind” the project – at this point I just hand edited the sln file to rebind it to the proper location.  After that everything seemed to be OK.

Just to make sure, I decided to open up my SourceOffsite client (SourceOffsite is basically a 3^rd party client/server product to allow access to SS over TCP/IP) to verify things would look OK to the remote devs; but where’s the stuff I just checked in?  After some searching through the SOS forums I found out I needed to “Refresh Project Tree.”  That showed me the new files, but now I noticed the versions were incorrect.  I then had to get latest and overwrite local changes (even though I already had the latest) to update SOS on my client.  So now I have three possible points of contact with the source control database, and they seem to all have their own view of what’s going on.  This just scares the hell out of me, and makes integration painful.  Integration should be easy!  After all, we want everyone to integrate their changes as quickly as possible.

As per our current team rules, I then needed to send an email to everyone with a list of my changes.  Of course SS doesn’t have change lists so I have no way to know what the hell I just checked in.  We also don’t have a CC.NET server yet, so I couldn’t check there either.  Argh!

What a bunch of crap.  Something that should have taken me 10 minutes took me over an hour.  I think its time to setup an internal Subversion server to show everyone the way towards the light.

I just installed P4Report, which basically gives you ODBC access to your Perforce depot - pretty cool.  I can now whip out a status report for the week:

select user, description, date from changes where user in ('joe', 'dave') and timestampdiff(4, date, curtime()) < 7 and P4OPTIONS='longdesc' order by user, date;