Disclaimer

I am not an employee of MKS, Inc. I work for Wincor-Nixdorf International and we're only user of that commercial revision control system MKS Source Integrity.

Introduction

When I start using CC together with MKS, I got nothing than exceptions for the MKS sourcecontrol. Then I take a look at the source of net.sourceforge.cruisecontrol.sourcecontrols.MKS. I saw a command like rlog -q -d which is totally unknown in MKS, because all commands use the command line tool si. Therefore, I thought this probably was a version initially copied from net.sourceforge.cruisecontrol.sourcecontrols.CVS and start working to change it. For update/checkout the files from the MKS server, I use si resync. For retrieving some additional information like user name and checkin comment, needed for the ModificationSet, I use si rlog.

Luckily the latest version of CC (2.3.1) has fixed most of the MKS issues. There were still problems with the mksant.jar file, but those have been remedied in the attached version in the zip file. The zip also contains example config.xml, and some ant scripts that complement it well. You do have to keep in mind 2 current limitations.

• getting the CC changelist actually does a full resync of the sandbox (instead of just getting the list of files, it actually pulls them down also)
• there is no 'si add' functionality in the ant tasks included in mksant.jar. So if you need to do an add, then you're going to need to write an ant <exec>

Prerequisites

1. The sandbox must always exists. The MKS sourcecontrol are unable to create the sandbox for you. In principle, this is not a real problem as long as the underlying MKS command si are able to handle such a task, but in this initial version I don't create a sandbox during runtime. If you not always create your sandbox, see si createsandbox for more information. You can also use the ant sicreatesandbox to create your sandbox for you.
2. You have already logged in into the MKS Server. This should be done in your bootstrap section by the ANT task siconnect. See the sample config.xml file. The underlying java class is situated in the mksant.jar which is available through the MKS Customer Community, and attached here. Since this (and the corresponding sidisconnect) anttasks are only small wrapper for the command line call of si, this could be done in later versions by the MKS sourcecontroller itself. You should call the sidisconnect task after your build, e.g. during your publishing phase.

Configuration

The new MKS source controller has the following attributes:

Here an example: Assume, I've created my sandbox in my home directory /home/dom. The name of the project I need to checkout is Info.pj. This project, which is a subproject within my sandbox, resists in Products/Info relative to my sandbox location. The resulting configuration looks like:

<mks localworkingdir="/home/dom/sandbox"
project="Products/Info/Info.pj"/>

Missing attributes In order to fulfill the required JUnit policy, my first JUnit testcase not only check the existence of a value for localworkingcopy , the path given with that value was checked too. But because of the OS depended path values needed to set as localworkingcopy I removed the check for existing directories in validate. Furthermore, the value for attribute project is also only checked against NULL.

Runtime

During runtime, the appropriate command line is started. The si command returns all filenames which are handled. In order to reduce to output (and 'cause it looks pretty well... in my eyes), for every 20 processed files a dot is printed. But if a diff is found and a file is resynchronized, that file is mentioned. Additionally, a second command is called for that file for retrieving the user name and the checkin comment for the last modification. These informations are logged in DEBUG level, so modify your log4j setting for verbose mode.
You should see something like that at your console:

[cc]Mai-17 14:04:01 jectController- info Controller: build progress event: checking for modifications
.................
[cc]Mai-17 14:04:02 MKS           - /home/dom/sandbox/Products/Info/v2/Server/base/antfile-checkstyle.xml: checked out revision 1.2
....................
[cc]Mai-17 14:04:03 MKS           - resync finished
[cc]Mai-17 14:04:03 odificationSet- 1 modification has been detected. 

Known Issues

MKS Modificationset This issues was resolved in 2.6.2.

There is a problem with the way MKS handles successive modifications. A fix was added to maintain a running list of modifications in case of a checkin during the quiet period (this is caused by MKS' inability to show differences between two timestamps) but this running list is never cleared after a successful build. As a result, once a successful build is triggered, it will build again every time during the interval, adding new modifications onto the list.

A JIRA has been submitted with code changes to address this issue.
http://jira.public.thoughtworks.org/browse/CC-467