As promised, I’m continuing to answer questions posed during my recent Subversion 1.7 webinar. Today’s batch of questions were mostly queries about the release itself — whether it brings some particular feature or fixes some particular problem. Admittedly, much of what folks were asking about is not part of this current Subversion release, which can make for a somewhat disappointing read. But I would urge readers to keep the context in mind: these questions were asked immediately after I spend a half hour or so talking about all the things that Subversion 1.7 does deliver.
So without further ado, here are today’s questions and answers.
Q: We have been running into problems with working copy corruption in working copies which contain many large binary files in a single directory. Will Subversion 1.7 be more robust in this scenario?
Subversion has a great track record when it comes to avoiding corruption and data-loss scenarios, and is used by many organizations with massive data sets consisting of many large binary files, so I’m surprised to learn of your problem. Without fully understanding the root cause of the working copy corruption you are seeing, I am hesitant to claim that Subversion 1.7 delivers specific improvements for this problem. Given the vast number of improvements delivered in WC-NG, though, consider me cautiously optimistic about your case.
But let’s be scientific about this, shall we? Perhaps you could upgrade a single user to the most recent 1.7 release candidate (1.7.0-rc4, at the time of this writing) and see if the problem goes away. You should be able to safely upgrade just one user to 1.7 with zero impact on the other members of your project. If the problems appear to be resolved, great! And if not, then I’d encourage you to contact the Subversion community or your Subversion Support provider about this problem so Subversion’s developers can better understand and fix the problem you are seeing. (If you don’t have a Subversion Support provider, please consider CollabNet’s offerings in that space — see http://www.collab.net/support/subversion/ for details.)
Q: Our users currently have to use web browsers to determine their particular project’s URL. Can the Subversion 1.7 client display a “collection of repositories” HTTP page?
No, the Subversion 1.7 client does not offer such a feature, but it sounds like an interesting idea. If you have a suggestion for how this feature might work if added to Subversion, let us know at dev@subversion.apache.org!
Q: Does Subversion 1.7 deliver the obliterate feature? If not, will CollabNet be addressing that feature?
There was a good deal of noise made during the Subversion 1.7 development cycle about a forthcoming obliterate feature, and even some trivial amount of progress made toward that feature. Unfortunately, nothing meaningful resulted from those efforts and users were left holding only empty promises. CollabNet, as the only company that has been an active sponsor of Subversion development throughout the entire history of the project, has been working with the community all along to resolve the difficult design challenges here. From our uniquely experienced perspective, we at CollabNet believe that to solve the obliterate problem, Subversion’s repository design must be revisited. This is not the sort of feature that can be cleanly tacked on to the existing design.
The good news is that the Subversion developers have discussed the idea of a repository rewrite and recognize the value that such a major overhaul could bring. But that value comes at a very high development cost, so for now we’re prioritizing features and enhancements that bring more of daily impact to Subversion’s users. You can be sure, though, that when the community decides that the time is right for a repository redesign, CollabNet’s Subversion developers will actively participate in that effort.
Q: Is there any support for checking out a single file or do you still have to check out an entire directory?
At this time, you still have to check out at the granularity of a directory. Now, the sparse directories feature will at least allow you to check out a directory and include only a single file in it, excluding all other items that would normally have been in that directory. But alas, you still need the containing directory. There has been some talk amongst the developers of moving the working copy administrative information (the .svn directory) to a still-more-centralized location (such as the user’s home directory) in the future. That change could open the door to allowing single-file checkouts.
Q: What is the best locking strategy? Is it better to use built-in locking properties or to add customized hook scripts?
First, if you find that your reflex action is to lock a file before editing it without regard to what kind of file it is, you might have picked up some bad habits from lesser version control systems. (If this is a widespread problem in your organization, consider getting some professional Subversion training.) Having said that, there are appropriate occasions for locking, even in Subversion. Remember, proper locking is all about avoiding wasted time through better communication. When used correctly — to save your peers time wasted editing unmergeable files that you’re already modifying — it’s a good thing. When used excessively and unnecessarily, you may actually waste more time by forcing your team to serialize what could have been perfectly manageable concurrent file modifications. But I’ll spare you the sermon, as I’ve covered all of this already in the Subversion book: http://svnbook.red-bean.com/en/1.6/svn.advanced.locking.html.
I would suggest that if you must lock, you do so primarily using the built-in locking feature and that you set the svn:needs-lock property on files whose contents aren’t line-based (binary files) or for which merge conflicts happen often in your environment. Subversion clients will recognize the svn:needs-lock property and toggle your OS filesystem’s permission bits to mark unlocked files which need locks as read-only. This can serve as an immediate form of communication to the user that, hey, he needs to lock this file. And, of course, when he then locks the file, that action is itself a form of communication to his peers. (Are you sensing the importance of communication yet?) That said, Subversion won’t require that a file carrying the svn:needs-lock property actually be locked when you commit to it. Also, Subversion won’t require users to set the svn:needs-lock property on any new files they add to version control which might benefit from that property. So you might wish to use hook scripts for those bits of supplemental enforcement.
Q: Are there any plans to include labeling and the ability to use the labels to perform builds?
The Subversion developer community is not planning to add a labeling feature at this time. Subversion’s architecture differs significantly from many tools which offer this capability in that directories are first-class version control objects, not mere containers for versioned files. On the plus side, this is why tagging in Subversion is so simple and efficient versus the similar action in other systems. Unfortunately, a consequence of this design is that per-file-revision labeling — and a mechanism for using said labels in build contexts — is a complicated feature to develop.
Q: Does Subversion 1.7 allow you to graph the history of merges?
The Subversion core software is a collection of libraries and command-line programs, and the terms “graph” and “command-line” don’t intersect often. But the information required to create such a graph does exist within your Subversion repository if you’ve been using the merge tracking feature. That information is accessible through Subversion’s APIs (though perhaps not in a fashion which is particularly optimized for this sort of graph display). Various third-party tools and clients such as SmartSVN and Subclipse claim support at various levels of revision and merge graphs.
Q: Regarding the new ‘svn switch’ restrictions: if I’m trying to switch from “branches/v1″ to “branches/v2″, but accidentally leave off the “v2″ part, does Subversion consider the “branches” parent directory an ancestor of my branch?
An ancestral relationship, as it is used in this context, means that the two items share version history, not that one is a parent of the other in the filesystem space. Clearly the “branches” directory is a distinct versioned object from its own children. So in your scenario, ‘svn switch’ will now print an error that indicates that “branches” shares no common ancestry with “branches/v2″ (and that you can use –ignore-ancestry to bypass that sanity check). In fact, it was precisely this scenario that caused me to introduce this additional sanity check into Subversion, as I seem to accidentally leave off that final branch-name far too often!
Categories: 
Tags: 
