We’re doing a big project at work that involves splitting up a large codebase into lots of little projects. The general methodology is:
One of the problems that’s come up is that the codebase is a moving target; people not involved in the extraction are making change all the time. I use Fisheye notifications to let me know when a change has been made to the codebase, but that requires me to remember to set up the notification.
So I decided to write a Maven plugin that would iterate through all the files in the extraction target directory and see if there are newer versions in the codebase. This means getting the info per file up until the point it was copied and then checking the URL the file was copied from to see if there are newer revisions.
I started doing this by passing calling the Subversion command line client with the –xml option and then using some XPaths to extract the necessary bits. There were two problems with this approach:
The former wasn’t that big a deal locally, but when I committed the unit test that used svnadmin, the tests failed on the CI server because svnadmin wasn’t on the path. The second was obvious while I was writing the code, but figured I’d deal with it later.
Rather than have svnadmin added to the path, I took a look at svnkit and found the API to be pretty clean. Things I really like (in no particular order):
Things I didn’t like:
But the biggest issue is speed, at least it seems to be. It sure seems slower when running my unit tests in Eclipse, but Hudson doesn’t show a big difference. Build #13 is when I introduced a minimal about of svnkit just to get svnadmin functionality working. Build #20 is all svnkit and is actually a few seconds faster. I’ll have to look more at this going forward.