I have intended for a long, long time now to write a blog post about one of my favorite soapbox topics of configuration management – tagging. It can’t be a hard topic to at least understand the principle given we apply tags to Flickr, hashtags to Twitter, and tags to Facebook. The idea is to apply a piece of metadata to some type of content in each of those tools. That’s what we’re talking about with Subversion with the key being that the metadata is applied to a revision of the folders and files that you’ve put under version control. The purpose isn’t that much different in many ways from tagging in those other tools. You want to draw attention to that revision by providing meaning to the set of folders and files that makes that set important to others, or important over the passage of time.

At best, most projects apply a tag to the revision they approve for deployment into production. That means that the casual user or the new employee months or years later can see on-going development through the individual commits and associated changesets, but it appears as though one day the project team was developing as usual and then the next they suddenly felt the code was worthy of being put into production. Now that’s not usually what happens (one can never say never in some organizations) as instead the project team has a logical and often multi-step process through which to move a revision of code before it is deemed production worthy. Without tags, that information is lost and when someone asks about the process and where it might be improved, they are left with harvesting human recollections that are inherently flawed. A negative event is much like a criticism in that it carries more weight than its opposite. I’ve heard it said that it takes seven compliments to overcome one criticism. I don’t if that’s the right ratio, but it is obvious that it isn’t one to one. If we want to be able to talk accurately about what has gone on historically, we need to have it recorded in a way that keeps it correct and unchangeable.

The value of knowing what a particular engineer did on a particular day at a particular point in time is of quickly decreasing interest over time. The value of knowing what happened in our process of moving developed code to production code is likely to become more value with the passing of time. Oftentimes we just haven’t been asked the questions that require us having that information available yet, so we can’t appreciate its value. We’ve also found that tagging, labeling, or whatever a previous tool did to track this data becomes a drag on performance and scalability over time. We might appreciate some value in having this data tracked, but the trade-off for performance and scalability didn’t make it worth the effort.

Subversion tackles the issue of tagging in the exact same manner as it does branching, but obviously the use of the result is quite different for tagging than it is for branching. The process of creating a tag is consistently quick and with low overhead no matter how few or how many folders and files we’re using. In most cases, we’re talking about capturing two small pieces of data to define our tag – a pointer to the folder at the top of the structure we want tagged, and a global revision number indicating the point in time we want captured. The time and space doesn’t change if the structure contains five folders and a hundred files or if it contains 500 folders and 100,000 files. That means there is no downside to using this functionality to capture the various stages of our “promotion” process, but there is certainly a lot of potential upside. Think about how you would answer the following questions accurately without this data:

• How many times was there a handoff from development to the release engineer before a successful test candidate could be built?
• How many times did we go through phase M before we were successful and able to move on to phase N?
• How much time did we spend in phase M?
• Where do we spend the most time in our “promotion” model on average?
• How much time does it take for us to get a release out once we’ve started down the “promotion” process?
• What files are doing the most thrashing through the “promotion” process?
• Who’s consistently responsible for the code issues that cause us to spend time fixing bugs and producing a new test candidate?

For many organizations applying these extra tags is a new part of their processes, but with a little time spent understanding the low cost and high value should make it obvious to add tagging. Even if your tags are more complex than the simple ones discussed above, you would be hard pressed to make a case that the potential value doesn’t significantly outweigh any cost. In short tagging is a #nobrainer.

Last Monday, I presented the webinar, “What’s New in CollabNet’s Distribution including Apache Subversion, Version 1.7,” with Mark Phippard, Director Engineering, Subversion and Integrations at CollabNet. We talked about the new features in Subversion Edge 2.1, the latest release of CollabNet’s Apache Subversion distribution. Specifically, we covered:

• Browser based management console, and Subversion browser
• Built-in update mechanism, for latest Subversion patches and features enhancements
• New: Back-up services, and dump/load features for repository migration and upgrade.

We encouraged our attendees to come to the session armed with questions. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.

If you missed the session live, you can watch the recording and download my slides. I also encourage you to download CollabNet Subversion Edge as is the answer for easy installation, administration, security, and governance of your Subversion environment. Also, don’t forget to register for our upcoming webinars. CollabNet offers multiple webinars a month that cover a variety of topics related to software development.

As promised, here’s the follow up to the live audience questions.

Q: What about Mac OSx? Any plans to support it?
A: Note that *client-side* Subversion has been supported on Mac OS for some time.   Since Subversion Edge is used for setting up a Subversion *server*, we’ve focused on environments that are traditionally used for servers – Windows 2008, LInux, Solaris, etc.

Q: Can you commit to a replica repository? If not what the replica is used for?
A: A Subversion Edge replica has a write-through proxy enabled, so commits can be directed at the replica, and commits will be proxied through to the back-end repository master.  Since the majority of Subversion transactions are read-only, the replica’s primary is meant for speeding up read access in remote locations, or for distributing read load across multiple replicas.

Q: What Linux distributions are supported?
A: Red Hat 5 is officially supported.  The software runs fine on quite a distributions that we’ve seen – including CentOS, SuSE, and Ubuntu.

Q: Any tools for managing custom Subversion hooks?
A: This is on our roadmap.  Of course, nothing prevents you from managing the hooks “manually” right now.

Q: Is there any repository migration support in subversion edge?
A: There are several choices for migrating a repository into Subversion Edge.  You can point the repository directory to a directory that stores older FSFS-based repositories, and have Subversion Edge.  You can also dump your old repositories (of whatever format), and load that dump file into a Subversion Edge repostory.

Q: Is SVN Edge meant to manage one repository (and optional replicas)? We have multiple repositories we were thinking of moving to an Edge server.
A: There is no fixed limit on the number of repositories that can be managed by Subversion Edge.

Q: Will there be a file/directory search function in the web UI?
A: Not currently planned, but feel free to bring it up in the forum, or add as a user request in our User Requests tracker:  https://ctf.open.collab.net/sf/tracker/do/listArtifacts/projects.svnedge/tracker.user_requests

Q: will user properties like email be available via an API for use in my own maintainance scripts?
A: We are working on a Rest API right now.  This sounds like a good requirement to have.  If you have any other requests for info available via API, please let us know on the forum or in the User Requests tracker: https://ctf.open.collab.net/sf/tracker/do/listArtifacts/projects.svnedge/tracker.user_requests

Q: What is the status of backward-compatibility with package containing Subversion v.1.6? Any serious limitations?
A: Subversion maintains backward-compatibility across all its versions.

Q: Is there a way to get email list of all users that are added in edge?
A: See the question on the APIs, above.

Q: Do you support Red Hat Enterprise 64 bit?
A: Yes!

Q: What is your technical roadmap for supporing Mac OS.  We intend to develop on Mac and deploy to Red Hat.
A: This is fully supported today, as answered above.  The Subversion client has been supported on the Mac OS for a long while – we have many developers here who use Mac OS.  The Subversion Edge *server* can be on a different OS, and Red Hat is officially supported by us.

More questions? Post them in the comments section below.

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.

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!