DevelopingChris

So we used TFS at work. It wasn’t the worst implementation of source control ever, but there was pain. You know contractors with locks on files from 7 months ago, who have moved on. Difficult to do continuous integration with, due to workspacing and having to have multiple copies of things just to do work on hotfixes.

So we are staring down the barrel of a big project, one that means an extended separation from the current code base. We need a sound branching strategy and we need it yesterday.

When I’ve needed this in the past, I’ve used Subversion, up until a few years ago when I discovered git. It was touted as fixing the many branches problem in open source development communities, a bigger problem than mine. So I’ve been using it on windows and linux for the past few years for every little piece of code I touch. Also I keep my home documents and our image library in git, because synchronization of backups is simpler.

So we have a problem, and a solution, but I couldn’t think of a very good strategy to bridge the gap short of writing a translator. It turns out after consulting stackoverflow, this was a solved problem.

There is a git plugin which connects to TFS and pulls down changesets applying them directly to the git snapshot store, with versions in the comments as to where and who did it in TFS.

There were a few small problems when doing the conversion. Git-TFS, depends on a c# based object model for the git CLI. This c# wrapper is not very good at managing memory on handles to shell calls. So I actually ended up forking the code and debugging it while it converted to make it work in batches and then dispose of its space and keep going. Secondly I had to run in a very minimal mode on my box so that enough memory was available. The final problem was a very large installer of a third party library stored in our binaries repository. The solution was to delete it and remove it from history in TFS, and then all was good.

Other things to look out for. Really really long paths. we had a file that was generated by a microsoft code generator whose path from the base of our solution is 230 characters deep. So if you put it more than a few directories deep, git cannot perform file operations on it, because its too much for the operating system, windows 7. The solution is to keep it close to the root of your drive, which is hacky, but the other option is to fix something that isn’t broken.

Now we have a nice git repo, with 7000 commits, that is ready to go.

On a side note, we used the Turnkey linux version control server. Which meant that we had a linux box, up and running a central server with backups, in vmware, in only the time it took to download the virtual image. If you have a server 2008 box handy this isn’t a necessity, as you can run the central server on iis 7.

I’ve recently started on a project that has been using web deployment projects. These things are an animal all their own.

There are so many problems that we ran into, I’m just going to list a few.

1. You need to create deployment projects for each environment to get config section replacement to work properly
2. It  locks the files in the source and target directories, if for some reason it fails, sometimes you must restart your box to get them back.
3. There is no way to just exclude a directory in the setup of the project, you have to close your solution and backdoor edit some xml to accomplish this.
4. You have to add projects to your solution, which basically slows down all your actions throughout the day.

These projects are awesome if  you are in a large enterprise where you need to just hand an installer to your web people and get it on the server. However, if you are a multi dev shop that needs automated deployment to a test server, save yourself the trouble.

I have a few posts on deck explaining how I use alternative tools to accomplish this. I’ll have examples in Nant and msbuild, and maybe even in ruby(rake) or python (straight up). Currently I use Cruise Control .net in order to trigger and run the scripts. I’ve been told that Hudson is a viable alternative. If enough people want to see it I’ll gladly try it out and see if its easier to setup and get running.

So if you are starting a project, just say no to web deploy projects, just write a build script in whatever language you know and don’t bother with the headaches of web deploy projects.

Alternatively, if you think that they are the bees knees, I’d love to hear how you get around my problems with it.