Subversion Rules!

I've been using Subversion for a while now.  Not sure exactly how long, but about a year, I'd guess.  Before that it was CVS for a number of years.  I have to say, first of all, if you're not using version control, start.  It's worth a bajillion times more than the few hours it'll take to set it up.  Second, the Subversion guys had their heads on straight.

I just tried externals definitions for the first time this evening, and talk about sweet.  Basically, they let you store (via Subversion properties, aka in-repository metadata), references to external projects subversion repositories, and allow you to transparently work with your multi-repository working directory in totally supported fashion.

Perhaps an example would be good.  I'm working on a CFUG presentation on JS remoting, and I'm using Neuromancer and as part of it.  Since both have Subversion repositories, and I have commit access to the Neuromancer repository (and may want to commit bug fixes while I'm working), externals are perfect.  I define a simple svn:externals property on my root directory, and then do an svn update, and BAM, I have my working directory updated, including fresh checkouts of the Neuromancer and code as well.  Make some mods, run svn status, and again, all the mods on all three projects are nicely laid out hierarchially, ignorant of the fact that they're source resides in three totallly separate SVN repositories.

Also, if I were to check out a fresh working copy on some other machine, guess what happens?  I also get the two external projects for free, because the external references are part of the SVN metadata, so they're included, and they're versioned.  All for free.

Now this might not seem like a particularly useful feature, but perhaps you have intra-project dependancies, and you need your app to rely on a specific version of a module that is also tracked in your same SVN repository.  Create a tag for the sub module, and create an external definition for that tag.  Then, until someone updates the svn:externals property, everyone will always get that tag of the submodule, regardless of where the submodule's development takes it.  Better yet, when you update svn:externals, as soon as you run svn update on your working directory, you'll magically get the new version of the tag.


11 responses to “Subversion Rules!”

  1. michael white

    lateley I've been thinking about learning to use some version control thingy for my coldfusion projects. at first it was no big deal because it was all internal stuff for my job but now my job is asking me to do coldfusion development for our customers and it seems like it become essetial… I've heard good things about subversion and I want to try it but what's the best way to get started? is there a tutorial somewhere? a book? I've never used version control… where to begin…

  2. Barney


    Best place to start is probably There you'll find links to the book, FAQs, the downloads themselves, and most everything else. The book is the complete text of the hard-copy version you can get in a bookstore, and totally free.

  3. Leslie

    I am trying to get adoption of subversion within my new organization which is a ColdFusion Shop. Are there any issues or "what out for"s in using subversion and ColdFusion together? How have you managed multiple people working on the same webserver in Coldfusion but with different working copies.

    Recommendations or thoughts appreciated.



  4. Barney


    Subversion and ColdFusion don't really have any relationship. It's Subversion and some text files, and then separately, version control and ColdFusion.

    The first is simple: you just manage your CFM files (and JS, CSS, images, etc) like any other files inside a Subversion repository.

    The latter is a bit more complex, because ColdFusion is a server-side application. You should still maintain the standard "one working copy per developer" paradigm, as with any other project. Ideally, each developer would be running the code on their personal workstation using CF Developer Edition. That's not always viable, so a shared server can be used, but each developer should still have their own working directory, configured with their own virtual host backed by their own instance of ColdFusion.

    In either case, you'll want a shared dev server for doing intergration builds and stuff, since with larger teams the limitations of Developer Edition will get in the way of people collaborating on stuff.

  5. Tuggle

    I just got setup on svn thanks to all the community's blog entries.

    You lost me there when talking about the tag directory. I have a general idea of how it's designed to be used, but when trying to picture it in action, I come up empty. Maybe that's okay for now. But if you ever want to write about it in a little more depth, I'm sure you'll have some eager readers, as I have not seen anyone else (at least in the CF community) praising it's use.

  6. Laurent

    I am convinced that the external definition feature is a great help when your working on multiple repositories and agree we what you wrote in your first post.

    However there is a catch (and this is the reason I'm crawling the Web to find the right answer). Like you said, when you have inter-project dependencies, you create a tag on the source project and update the external definition in the target repository.

    But what if you don't have commit access on the source repository (like in my situation). When I tag my target repository I want all the intenal and external definition to be tagged. How can I do that?

    Is there is a magic script somewhere that can walk my working copy, find all my generic external definition, magically changed them to external definition to a specific revision and tag all that?

  7. Laurent

    Actually that's already what I am doing. I track external projects into vendor branches, create tag on the vendor branches, and define externals definitions on particular vendor tag. It works fine. Just a lot of tracking to do. I am lasy and wanted to find a quicker solution, where I could point to a particular revision of a external respository.

    Being lasy is not an option. Thanks — Laurent

  8. Laurent

    Yep! I realized today that I overlooked the manual.

    I found today a perl script,, available on the tigris web site, that does what I want. It updates the external definitions automatically before doing the copy. Two modes are supported: –tag which update the external definitions with the current revision of the external repositories; –branch which creates new branches in the external repository and change external definitions accordingly.

    Lazy is finally an options :-)

  9. Christophe

    I tried the tool described by Laurent. First this script doesn't work on Windows, you'll need to fix it by adding "\"" around paths (run the script using "–verbose" to see where this is missing).
    A second problem with this tool: it doesn't handle recursive externals ('externals of externals'): it will only tag the first layer of external, nothing is done for the externals above that.

    A is an external to B (on HEAD) which is an external to C (on HEAD).
    I want to tag my version A.
    the tool will add "-r XX" for the external to B, but C might be modified after that and my tagged version gets screwed.

    Anyone has a solution for that?