Monitors and backups TeamCity configuration to a TFS repository.
The application has not been tested extensively and might wipe out all your data. Backup your data before trying it.
Before pointing it to a real TeamCity configuration folder try pointing it to a fake folder containing some xml files and see how the application behaves.
The application is built with VS2010 and targets the .NET framework 3.5.
The application is able to syncronize
project configuration files to a TFS 2010 repository. This is accomplished by performing a one-time syncronization on startup and then monitoring the TeamCity configuration folder for changes.
Note that synchronization is carried out with brute force. While new and deleted files are easy to spot changes are not, so each time a synchronization is performed all files existing in both the configuration folder and the workspace are checked out in the
workspace, overwritten with those from the configuration folder, and then checked-in.
Unless you have many projects on TeamCity you should not experience issues as TFS is smart enough to figure out if a file being checked-in has really been changed or not. In other words, to check if a file has changed I would have had to keep a hash of it,
but I'm relying on TFS to do that for me.
The project's source control repository contains a root folder with some dummy data on which I do tests, you can safely ignore it when looking at the source.
The project comes as a standalone console application which accepts no command line switches and can easily run as a Windows Service or a scheduled task.
Extensive logging is performed via NLog
and is easily customizable. By default it logs both to the console and on rolling files.
Application options are configured with the .NET configuration file, which contains extensive documentation about configuration options.
Logging is configured with the NLog.config file.