The amazing adventures of Doug Hughes

On a bit of my own time last evening, I was looking over the beta version ofBroadchoice Workspace(which is pretty durn cool in and of itself, even if it has a ways to go before it’s completely ready for prime time) and decided to post the suggestion that they integrate document versioning into the product. For the things I’d use it for, versioning would be pretty important.

My suggestion was to do something like integrateSVNKit(the only pure Java library for accessing Subversion servers) into an application and, programmatically, create a new repo folder and a new working copy in the webroot to hold uploaded files it’s practically built-in versioning, really.

Incidentally, if you use Subversion and Eclipse, it’s likely that you have used SVNKit because it’s one of two ways (and until relatively recently the ONLY way on OSX) to get Subclipse working… SVNKit is bundled with Subclipse. More on getting it running in a minute, but first, some thoughts…

Think of this in terms of something simple, like an image gallery. As you add images, they’re added to source control if they’re not already under source control. If they are, then nothing’s done at upload.

Then using cfthread you fire a commit for every file you upload with an atomic commit message. When you go to do back-ups on the server, you don’t back up the working copy, you back up the repository. This would give you the ability to use files from disk as though nothing unusual was happening, but it would also allow you to do clever things like have preconfigured repository locations that your application depends on and, onApplicationStart(), are checked for. If they’re missing, they’re simply checked out to the correct folder under the webroot, most likely.

The possibilities really are endless. Let’s takeblogCFCas an example (kudos toRay). Let’s say when you go to download the application, what you really get is an installer that asks you where you want the root folder of the application set up, or the webroot into which you want it installed, and your CF Admin password. It then goes on to use SVNKit to checkout the source from the server, CF’s AdminAPI to create the datasource, and cfquery to create the db tables. One of the first functions I played with last night was Repository.getRepositoryVersion(), which returns the current repo version from the SVN server. Since you can also get the repository version of the working copy, we now have a pretty foolproof built-in mechanism to manage either auto-updates or a “check for updates” button in the admin section of the application. Now imagine what it would be like if something like this were added into the CF Administrator under a ColdFusion Applications section. The UI gives you fields for the install destination, the SVN Repository information (URL, repo path, username and password) and a radio button for doing an export from the repo or a checkout. If Adobe were to get really clever, they could publish a whole application distribution system that allows you to include a post-checkout file that could create databases and DSNs, create tables and folders within that DSN, add mappings, etc. And since you’re already inside the CF Admin when you do this, you’re a trusted user! Beyond that, CF Admin would give you buttons to check for updates, replace from repo, the ability to specify an interval for background updates, and the reload URL for the application to be fired off once an update has been pulled from the repo. And if you’ve got write privileges to the repository, it could even let you commit local changes to the server.

You know what would happen if Adobe did this? People would complain that they can’t swap SVN out for CVS or Perforce. OK, I kid (sort of). I think something like this would make sites likeRIAForge.orginto powerhouse software distribution systems and gives ColdFusion an even greater claim to “make hard things (like installing server software) easy”.Seriously, though… it’s things like this that get my imagination running and my coding juices flowing and make me really want to see things like this put to heavy use in the ColdFusion world.

As for usage, there are 2 things you need:

Next, you’ll simply need a code block that looks something like this:

<cfset cpRoot = "/path/to/download/svnkit-">
<cfset classPath = [cpRoot & "svnkit.jar",cpRoot & "svnkit-cli.jar",cpRoot & "trilead.jar",cpRoot & "jna.jar"]>
<cfset loader = createObject("component","JavaLoader").init(classPath)>

<cfset loader.create("").setup()>

<cfset svnDavRepoFactory = loader.create("").setup()>
<cfset svnRepoFactory = loader.create("")>

<cfset svnRepoUrl = loader.create("org.tmatesoft.svn.core.SVNURL").parseURIEncoded("")>

<cfset svnWcUtil = loader.create("org.tmatesoft.svn.core.wc.SVNWCUtil")>
<cfset svnAuthManager = svnWcUtil.createDefaultAuthenticationManager("username","password")>

<cfset repository = svnRepoFactory.create(svnRepoUrl)>
<cfset repository.setAuthenticationManager(svnAuthManager)>

<cfset latestRevision = repository.getLatestRevision()>
<cfdump var="#variables#" />

At the very least, if you check out a working copy of the application on production, it would be mind-numbingly easy to set this up so that it does an SVN update as part of the application reload routine. So all in one step you update from the repo if the working copy’s revision number is lower than that of the server, clear the trusted cache, and reload the frameworks and libraries necessary to run the application.

Kick me in the knee and call me a geek… I like it, and I can’t wait for an opportunity to use this in a project. Yeah, I get excited about int’restin stuff.

Comments on: "SVNKit, ColdFusion, and you… very cool Java+CF stuff" (11)

  1. Jared Rypka-Hauer said:

    Yeah… that’s a bit old and uses a version of SVNKit from before the product was renamed from JavaSVN to SVNKit… so it’s at least a couple minor updates old. Still, it’s cool to see people using it for anything at all.

    One of the other things that I wanted this post to hilite, though, is the use of the JavaLoader and the fact that the jar files don’t need to be added to the server, they can just be added right into the application’s file system and loaded programmatically. Very cool stuff. I think the JavaLoader part is every bit as cool as gaining programmatic access to Subversion for applications to use independently of the command line or some GUI-based SVN client.


  2. Jared Rypka-Hauer said:

    Oh, wait… Rick, you’re the one that wrote the cfdiff repository viewer. Sorry, I thought it was someone posting a link to someone else’s thing. My bad. Not that it changes much but I’d have phrased my response slightly differently. 🙂

    Anyway, it really is cool to see people doing stuff like SVN integration using CF. And using JavaSVN means you’re on an older (and slower) version of SVNKit doesn’t make the idea any less cooler. Does your implementation use a classloader, or do you have to dump the jar files into the server classpath and restart it? Just curious, because I find the classloader to be One Cool Toy… being able to deploy Java-based classes to the server without having to have them in the classpath makes so many things so much easier. 🙂


  3. No problem — I certainly wasn’t offended or anything. I got my version of the code up and running just enough to be useful, and haven’t really touched it since then.

    Mine assumed that you had actually installed the JavaSVN class libraries, but I believe Russ Johnson’s Trac-Fu and Skweegee projects used the classLoader.


  4. Jared Rypka-Hauer said:

    I know Skweegee uses the JavaLoader because there was one piece I was missing in the process (creating an instance of a static class) and it wouldn’t work without it… I had to check the Source.cfc ColdBox handler to find the one missing piece. It’s actually moderately complicated in terms of getting a repo up and running, but once you’ve got the system down it’s not too bad.

    I’m trying to talk a client into letting me add the auto-update code to their application reload code. The webroot for the app is actually a working copy so that when we deploy new code to the server we can use cfexecute to run svn update on it. I thinkn adding it to the application reload code would mean less margin of error (i.e. forgetting a step) and faster reloads. We shall see.


  5. Sean Corfield said:

    Glad you like the Broadchoice Workspace. Interesting idea about versioning files within it – good suggestion! We just pushed Beta 1 Build 2 today with the addition of groups to provide separate sets of people and spaces, as a first step for planning external system integration points. We also redesigned the spaces navigation and fixed a bunch of bugs (including the case sensitive contact sorting issue you raised!).


  6. Marcuski said:
    Check out this cool mini fighting game


  7. Robin Hilliard said:

    Hi Jared,

    Thanks for the post, it saved me a lot of time getting SVNKit integrated into the CF build server I’m working on. Just a little note (I’ve already sent Mark the details) I was unit testing a connect/get info/export scenario loading these classes and SVNUpdateClient with the class loader, and after about 70-80 cycles I get a Java PermGen out of space error – which is still quite respectable, and gives a rough upper limit to the number of times you could use class loader with libraries like this.


  8. daniel fredericks said:

    I see the svnkit is used in skweegee and project tracker on riaforge. All they are using it for is to view repositories and differences. Has anyone used the svnKit to do working copy updates? I would like to use it to do an update on my working copy using project tracker. I tought I might be able to use the svnKit, but I am not familiar with it, and not very familiar with Java.
    Any ideas would be greatly appreciated.



  9. Where can i have more info on this ?



  10. Camn cold fusion be used to communicate with SVN


Comments are closed.

Tag Cloud

%d bloggers like this: