Hi.
So, after the yesterday's meeting, it looks like that we want to have a subversion sensor (which I think is very cool because subversion is multiple times better than cvs, I'am using it for all my personal projects...).
Implementing a subversion sensor could be very easy as subversion supports something they call 'hooks'. (see http://svnbook.red-bean.com/en/1.1/ch05s02.html#svn-ch-5-sect-2.1).
The main idea is that you create a hook script or a hook executable (which means for windows a .bat, .com or .exe or for unix/linux anything which is executable from commandline) and connect it to one of the existing hooks (which are, at the momemnt post-commit, post-property-change, pre-commit, pre-property-change and start-commit). The hook scrips or executebles are provided by a command line parameter list with a) the repository-path and b) the revision of the new change. With that, the script could access the according commitlog and gather all needed information (like user, time, size, churn, ...). The very cool thing about that is that a subversion sensor with that architecture would be a "real time" thing, so everytime a commit occures, the script is executed and sensor data is sent. This is ways cooler than the actual CVS stuff.
The only problem is, that subversion does not provide a "real, official" java client library (as far as I know - at least there was no 5 month ago when I played around with that stuff), they have just the C++ client lib, and any java client is forced to use that lib by using native calls (which can be quite annoying). To support tat, Tigris provides to libraries: The quite low-level JavaHL library and and other one which name I forgot...
There is an project out called JavaSVN which tries to create a java-only client library, but they are still beta (V0.8). But still, using this might be the best idea as JavaHL is a real pain (I hated it like hell, it was unstable, uncomplete and very dirty).
Hope this might help the poor guy who will develop the Subversion sensor.
Cheers, Christoph
