Last week, my colleague Bob Jenkins and I presented a webinar introducing folks to the forthcoming Subversion 1.7.0 release. As always, there were right many questions asked of us during the designated Q & A period and not enough allotted time to answer them all. So, we promised to answer the unanswered questions here on this blog. This is the first batch of those questions and our answers. We’ve grouped questions into general categories, merged similar or related questions, and slightly rephrased some questions based on our interpretation of them. If you don’t see your question here, keep watching this space — maybe we’ll hit it in one of the subsequent batches of Q & A responses.
Q: Can a pre-1.7 Subversion client communicate with a Subversion 1.7 server? How about the opposite: a 1.7 client and an older server?
Yes. The Subversion project has always guaranteed client/server compatibility across all 1.x releases. Obviously, you might miss out on some of the newer benefits when you use older clients or servers, though. For example, you can use the latest and greatest client, but if your server is still running Subversion 1.4, you won’t have any merge tracking capabilities (added in Subversion 1.5) or server support for the HTTPv2 protocol changes (new to Subversion 1.7). Subversion will still function properly, but may operate more slowly over HTTP networks; you’ll still be able to perform merges, but Subversion won’t track them for you.
Q: Will the language bindings (Perl, Python, etc.) be updated to take advantage of Subversion 1.7?
The language bindings maintained by the Subversion project tend to track the Subversion C API and changes made to it pretty closely. This is facilitated by the fact that the Python, Perl and Ruby bindings are mostly auto-generated from exactly that C API.
The Java bindings have also been updated for 1.7. In fact, they’ve undergone some pretty significant changes in 1.7. First, due to the move of the project to the Apache Software Foundation, the JavaHL bindings package now lives in the org.apache.subversion namespace. (We’ll still ship the old org.tigris.subversion package for compatibility, of course.) Also, the maintainers of that package have begun taking advantage of some of the language features of Java 1.5, which is the new minimum Java version requirement.
Q: How do I upgrade from Subversion 1.6 to 1.7? Will every client need to update their working copy the first time they try to access it after upgrading?
I’ll answer these in reverse.
Working copies will not need to be updated the first time they are accessed. They will, however, have to be upgraded. The 1.7 command-line client introduces a new ‘svn upgrade’ subcommand for transforming a pre-1.7 working copy into a 1.7 working copy. This is a local metadata storage change only, though. ‘svn upgrade’ does not contact the server and does not modify the content of the users’ working files. That said, it is a significant metadata storage change, and one that will take longer to complete on larger working copies.
As for the actual upgrade itself, you’ll want to do this in the fashion recommended by your Subversion package provider. If you are using your operating system’s distribution-provided Subversion packages, you should be able to update those packages as you would any other package, resulting in the removal of the old Subversion binaries and the installation of the new ones on your system. Admins who are hosting Subversion services using CollabNet Subversion Edge can take advantage of that software’s build-in upgrade functionality, too. You’ll probably want to upgrade all of your Subversion-related client-side packages at the same time (which implies that you might not wish to upgrade any of them until you’re sure that they all have posted new releases offering Subversion 1.7 compatibility). The reason is due to the first part of my answer: you must upgrade your working copies to the 1.7 format in order to use them with Subversion 1.7, and once you upgrade them you cannot use them with older Subversion releases.
I will note here, though, that the Subversion project strongly recommends that you run ‘svn cleanup’ on your working copies before upgrading to Subversion 1.7. This is because working copies with metadata in an inconsistent state may not be able to be successfully upgraded. See http://subversion.apache.org/docs/release-notes/1.7.html#wc-upgrade for more information.
Q: For users with multiple working copies from multiple repositories, how do you recommend upgrading all those independent working copies at once? Since the 1.7 TortoiseSVN client does not show icon decorators on 1.6 working copies, it could be difficult to find all old working copies after upgrading.
That’s a great question. I reached out to Stefan Küng of the TortoiseSVN project to get his perspective. He tells me that TortoiseSVN will identify pre-1.7 working copies as being under version control using the normal icon overlay for versioned directories, but only if you have the “Show excluded root folders as normal” option enabled. (Note that TortoiseSVN will not to use a distinct icon overlay for the special case of “working copy in need of upgrading”, just the normal “this is versioned” icon. See http://tortoisesvn.net/faq.html#ovlnotall for why this decision was made.) So, as long as the aforementioned option is enabled, you should still be able to see that your old working copies are, in fact, working copies. It’s just that when you right-click on such a working copy, you get only the “SVN upgrade working copy” menu option. This is described more fully in the TortoiseSVN 1.7 release notes: http://tortoisesvn.net/tsvn_1.7_releasenotes.html#wcformat. Note that one down side of the “Show excluded root folders as normal” option is that it is expensive, performance-wise. So Stefan recommends that folks enable the option only until they are sure that all their working copies have been upgraded to the 1.7 format, and disable it afterwards.
Q: When will CollabNet officially release its certified versions of the Subversion 1.7 server and client?
CollabNet’s certified packages are typically released within 48 hours of the open-source project’s release of the corresponding source code. As good citizens of the Apache Subversion ecosystem, CollabNet does not release binary packages of Apache Subversion software that has not received the prior blessing of the Subversion developer community. And as good stewards of your trust, CollabNet does not release binary Subversion packages until we’ve completed our thorough quality assurance measures. As a result of these promises made to you and to the greater Subversion community, this typically means that our packages come out a day or so after the Subversion project’s source code releases.
Q: Will CollabNet update Subversion Edge to Subversion 1.7 soon after the 1.7 release?
Absolutely! We’re already in the process of finalizing the next release of Subversion Edge, and it will carry Apache Subversion 1.7. Expect a new Subversion Edge release shortly after the release of Subversion 1.7 itself.
Q: When will binaries be available for OS X?
Q: Can I get binary packages for the AIX platform?
I’ll these two questions simultaneously. The Subversion project maintains a list of known providers of binary packages for various platforms at http://subversion.apache.org/packages.html. Unfortunately, I’m unable to predict the release schedule of any of the various third parties who generate these packages. Even the AIX and MacOS X packages hosted at openCollabNet are not actually generated by CollabNet, but by awesome volunteers who build these packages and post them to CollabNet’s hosting platform. Experience teaches that Subversion 1.7 packages for both of these operating systems should be available relatively soon after the project releases the 1.7 source code, though.
Q: Will we be able to get 1.7 compatibility in the various third-party Subversion clients and integrations (Eclipse, TortoiseSVN, VisualSVN, Microsoft Studio, etc.)? When?
Many of the third-party providers of Subversion clients and integrations are already working toward Subversion 1.7 compliance, and some have even completed this work. For example, you can grab builds of TortoiseSVN that are already fully integrated with Subversion 1.7’s recent release candidates. The leaders of the AnkhSVN and Subclipse projects have informed me that they’ve mostly finished their planned changes for Subversion 1.7 support, and that their new software versions should be available shortly after Subversion 1.7 itself is released. Contact the individual communities behind these tools for the specific details of their release schedules, but it looks as though 1.7 will have great tool coverage — at least for the most commonly used tools — within mere days of its release!
Q: When will the Subversion book be updated to cover Subversion 1.7?
The Subversion book has already been updated to cover most of the changes in Subversion 1.7. I currently lack updates for chapter 4 (“Branching and Merging”) and chapter 9 (“Reference”), but hope to get those shortcomings addressed soon. You can watch the progress on this task via the following wiki page: http://code.google.com/p/svnbook/wiki/SvnBook17Status
* Apache, Apache Subversion and the Subversion logo are trademarks of the Apache Software Foundation. Subversion® is a registered trademark of the Apache Software Foundation.