If you set up a TeamCity server, don’t tell it to check out your project into a path that is root of a drive.

Don’t Try This At Home Drive

You would think that checking out ModuleX into “Checkout Directory” C: would result in

C:ModuleX

That’s how CVS and SVN clients normally operate and you would expect.

But it looks like TeamCity takes the root of the module as the path itself OR it decides that the checkout directory needs to be emptied for some reason, possibly at config time to prevent any issues with dross left behind from previous builds?

So now I have established that TeamCity by default seems to empty the “Checkout Directory”

Which in this case is C:

I managed to fry two machines before working out that TeamCity has this highly dangerous gotcha.

The first time I thought this was a Windows Update that went rogue.

In the second machine I tried this on E: where TeamCity was also installed. 

Now I can’t uninstall TeamCity at all.

That’s two machines to rebuild.

Out Poor System Adminstrator (He made me type that) 🙂

I would not be upset if I thought I had done something stupid, like pressed the button that said “Delete Everything And Your Little Dog As Well”.

The default settings telegraph nothing of the impending right hook to your hard drive.

Mostly Harmless

My recommendation would be that the Config page warn that the directory will be emptied and maybe even give an obvious shrill warning if that’s the root of a drive.

Maybe C: should be right out?

Telling you where files would be created (and destroyed) would go part of the way to deciphering what you are going to end up with. At the moment its a black box of string concatenation via hidden logic with hidden results.

Now that I have the model of what is going on in my head I won’t make that mistake again.

Its just a pity that I had to learn it.