That Subversion is popular among Java programmers is no big surprise. If it needed proof, the huge line of people waiting to get into the “Subversion 1.5: Great New Functionality For Developers” session at the first day of JavaOne 2008 would have provided it. In a 50 minute session, the audience was led through the highlights of the upcoming release (“which should be out any day now”) by Michael Pilate of CollabNet.
The area that got the most attention is the significantly improved “merge” functionality. Subversion 1.5 will provide much improved support for common merge scenario’s like repeatedly merging changes made in a “feature” branch back to the “main” branch, while changes have been made on that main branch in the meanwhile. By Subversion keeping track of which releases have already been merged and won’t need to be merged again, the chances of conflicts during repeated merges are greatly diminished. Also, in many of the Subversion commands, additional support for accessing the merge history is built in. For instance, the “blame” command not only reports the person who created a conflict (the “MergeMeister” as Michael called him), but can also report the developer who is responsible for the code changes in the to-be-merged code. Finally, a new, graphical Merge utility has become part of the Subversion product, which can guide you through the Merge process in a step-by-step fashion.
Further new features include the possiblility to do have more control over exactly which code you do and don’t check out, by replacing the –recursive property used in many subversion commands by a –depth property. This will allow you to check out only parts of a directory structure (some demo’s on this would have been nice but were absent). What many developers not using graphical Subversion clients like TortoiseSVN will be releaved to find is the fact that the “mv” and “copy” commands _finally_ can use wildcards and be used to move/copy multiple files in one go. Also, while in older subversion releases there were certain operations that could not be grouped together in a single “atomic” commit (like moving and then renaming a file), all such restrictions have been removed in Subversion 1.5 due to “better housekeeping” in the Subversion server.
Of course, quite a few significant performance and scalability improvements have been implemented, and various “migration” scenario’s will be available to move from a 1.4 to a 1.5 repository, including a “lazy” implementation that will upgrade parts of the repository when you first use functionality that requires this, and a new “svnadmin upgrade” command that (if I remembered correctly) can be run on the repository while it’s up and running.
In short, the presentation provided a nice, insightful guided tour through the new Subversion release. Now let’s hold our breath and keep checking the Subversion website for the release!
