This is GREAT!  We've been using Subversion for almost a year now.
I'm excited to see Hackystat move to support it.  Here's a few more
links to Java and SVN related stuff.

--Tim

Eclipse SVN plugin (ships with JavaHL)
http://subclipse.tigris.org/
http://subclipse.tigris.org/#faq

JavaSVN
http://tmate.org/svn/

CruiseControl's SVN adapter (executes 'svn' in another process and
parses results instead of trying to call the libsvnjavahl)
http://cvs.sourceforge.net/viewcvs.py/cruisecontrol/cruisecontrol/main/src/net/sourceforge/cruisecontrol/sourcecontrols/SVN.java?rev=1.11&view=auto

On Tue, 15 Mar 2005 12:39:57 -1000, Christoph <[EMAIL PROTECTED]> wrote:
> 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
>

Reply via email to