Over the last 2 weeks I have been working on getting MKS fully integrated into TeamCity with no luck. I would like this post to serve as both a warning to others and a plea to JetBrains to please rethink VcsSupport for TeamCity.
For those of you holding your breath for an MKS plugin:
Dont. After wasting 2 weeks trying to integrate with VcsSupport, I can tell you that the best you can hope for is broken support at best - which I refuse to do.
It seems to me that VcsSupport was built entirely around functionality present in SVN, CVS, and to a lesser degree, Perforce rather than common VCS concepts (ie: a VCS will at least checkout/resynchronize/etc.). This makes it all but impossible to integrate VCS that do not follow that usage pattern.
Please consider the following suggestions:
1) Refactor VcsSupport to support primitive VCS operations only, such as checkout/resyncrhonize and returning a modification set based upon that rather than using awkward API's such as collectBuildChanges() and buildPatch(). If additional tracking is needed to support personal changelists etc. these should be handled soley by TeamCity.
2) Do not make VCS operations time-sensitive. If it is neccessary to track filesystem changes by time, TeamCity should track these changes internally rather than inflicting the work on VcsSupport authors. Some VCS (such as MKS) do not support collecting build changes or even project resynchronization by date which makes it impossible to use with TeamCity.
3) Do away with getContent(). Not all VCS correctly support fetching content based on dates. TeamCity should be intelligent enough to track changes itself, and look at the filesystem for the most current revision (or issue a checkout).
4) Documentation! I have been able to figure out how VcsSupport works in the wild only through bits from forum posts, decompilations, and lots of trial by fire. Please document these API's in a public javadoc rather than distributing a source .jar!