This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Subversion 1.7 Q & A, part 4
So… have you installed Subversion 1.7 yet? Are you enjoying the performance increases it brings? Is WC-NG your new best friend, or are you hanging posters around your home town which read: “MISSING: .svn folders. Last seen hanging around Subversion 1.6. REWARD OFFERED!!”?
Subversion 1.7 has been available for seven weeks now, and has already seen one subsequent patch release, with a second one (1.7.2) expected to be released today or tomorrow. Many of you have embraced this new version of Subversion; others have not. If you haven’t, and you aren’t quite sure what I’m talking about or don’t see the humor in my hypothetical poster’s wording above, perhaps it’s time for you to settle back into a comfy chair for about 45 minutes and watch the replay of my recent Subversion 1.7 webinar.
This post is actually the final installment of a series of follow-ups to that webinar, fielding unanswered questions asked of me and my colleague Bob Jenkins during that event. (For the previous posts, see part 1, part 2, and part 3 of this series.) Hopefully, you’ll find my answers enlightening. And if not, you can at least take comfort in knowing that I’ve run out of questions to (try to) answer!
Q: What improvements have been made to the WebDAV write-through proxy? Currently, if the master server is down, the slaves don’t work either — has this been addressed in Subversion 1.7?
I’m sorry to hear that you’re having troubles with your WebDAV proxy setup. My own experience with WebDAV proxies using Subversion 1.7 so far is that if the master server is down, the slaves continue to operate, albeit in a read-only mode. You can checkout, query logs, and so on, but simply can’t commit new changes or modify revision properties. If you’re seeing different behavior when your master server is offline, there might be a problem with your particular deployment scenario or possibly even a bug in Subversion itself that needs to be reported to the community. Don’t look for any specific improvements to this feature that are unique to Subversion 1.7, though — all the improvements made to the WebDAV proxy code in the 1.7 timeframe (which were mostly minor bug fixes) have been backported to the 1.6.x line.
Q: Is there a plan for supporting mirrors as part of Subversion itself instead of forcing users to configure and maintain those things?
The Subversion core software doesn’t really concern itself so much with its own specific deployment. You won’t see Subversion modifying your Apache httpd.conf file automatically, or generating its own repository hook scripts, for example. There are just too many different ways to deploy Subversion, too many different operating systems and platforms and such, etc.
Fortunately, CollabNet TeamForge 6.1 provides pain-free mirror maintenance as a value-add beyond what the core Apache Subversion distribution offers. With TeamForge, you can administer multiple Subversion Edge instances, and even configure some of your repositories on one Edge server to act as write-through proxies for other ones in another Edge server. Honestly, it’s the slickest packaging of the WebDAV proxy feature that I’ve ever seen. Check out the TeamForge 6.1 press release and TeamForge product page.
Q: We are using Subversion with LDAP Authentication. What is the best way to manage role-based access for users and project members? Do we need to use Jeremy Whitlock’s python script (http://www.thoughtspark.org/node/26)?
Jeremy’s script is useful if you need to replicate your LDAP groups into Subversion’s stock authz-file access control mechanism. But many organizations find that Subversion and LDAP are happier together and easier to administer when deployed on the server under CollabNet TeamForge, which offers real role-based access control for Subversion repositories and LDAP integration. Can you say, “No more editing access control configuration files”?
Q: What is CollabNet planning on doing with respect to their cloud offering? When will it upgrade?
CollabNet’s Codesion Cloud Services is currently still deploying Subversion 1.6.17. (If you’re interested, you can always see which product versions are deployed by Codesion at https://help.codesion.com/View.jsp?procId=e875af1afcaa7fc8e573946dfcc6a225.) But I have it on good authority that within the next few months, the upgrade to Subversion 1.7 should occur.
Q: We just upgraded TeamForge 6.1.0. How do we upgrade to the new release of Subversion?
My understanding is that the forthcoming TeamForge 6.2 will be the first TeamForge vehicle to directly offer a Subversion 1.7 integration. That said, you should be able to use TeamForge 6.1 today with Subversion Edge 2.1 as your Subversion integration server, and that will give you server-side Subversion 1.7. Of course, you can upgrade your Subversion clients immediately — they’ll work just fine against your TeamForge 6.1 server.
* Apache, Apache Subversion and the Subversion logo are trademarks of the Apache Software Foundation. Subversion® is a registered trademark of the Apache Software Foundation.