Your Subversion Structure and What It Says About Your Release Schedule
Recently, I had a customer ask me, “How can I give my UI code in Subversion its own trunk instead of having it in the same trunk as my services tier code?” This was an astute question. The customer had realized that her Subversion repository was structured with an implication that UI code and services code would be released simultaneously—an assumption that was turning out to be incorrect. Many Subversion users, even seasoned ones, wouldn’t have seen the connection between repository structure and releases. If you’re one of those people, permit me to explain. Meanwhile, for readers wanting a bit of an introduction to Subversion, you might peruse my previous post first.
As I mentioned in the previous post, Subversion convention suggests that a given stream of work be provided the following structures: trunk, branches, and tags. In general, trunk should contain the most current code and should be the primary target of a team’s development. Imagine, then, a scenario (such as my client’s) where both the UI and service tier code reside under trunk. Now imagine that this client wants to write a new UI for the same service tier. This second UI may serve a different purpose, be maintained by a different team, and have a different release schedule than the first. Imagine, too, that users of UI #1 discover a bug. As I suggested in my previous post, this might be a good time to create a branch to allow development to continue while the bug is repaired.
If the developers tagged the release before they deployed it (a good habit), they could easily create a branch from the tag, repair the bug, and re-release from the branch. The branch, however, would likely contain services, UI #1, and UI #2, even though the services code and UI #2 weren’t affected by the bug (as it is isolated to UI #1). This is confusing and makes maintaining the branched code more difficult.
Let me suggest a better alternative. Rather than putting trunk, branches, and tags in the root of the repository, a root-level directory should be created. Perhaps it could be called “services” in this case. “services” would have its own trunk, branches, and tags structure. UI #1 would also have its own, parallel, trunk, branches, and tags. When UI #2 is introduced later, it too will be provided a trunk, branches, and tags.
My suggestion is that all Subversion repositories should be structured with the assumption that they will contain more than one stream of work, and be responsible for more than one release train. My last post suggested that each team should be issued its own repository. The implication of these two suggestions together is that each team may simultaneously be responsible for more than one stream of work, an implication which I would now assert to be true in a complex multi-tier application. At this point, those of you who are build engineers are probably shuddering. Those of you who aren’t probably use Maven. But that’s an assertion for another post.
What, then–getting back to the title of the post–does your Subversion repository structure say about your release schedule?
- If you have only one set of trunk/branches/tags at the root of your repository it is targeted at one release.
- If your repository contains root directories, each with a trunk/branches/tags set, then it can support multiple releases with the caveat that build complexity increases if there are dependencies between artifacts for these different streams.
- If you don’t have a trunk/branches/tags set and your repository contains code (as opposed to documents, for instance) you’re doing it wrong. If you ever need to branch you’ll need to do a repository restructuring first.
If you find that your repository structure doesn’t match your needs, the good news is that Subversion handles such restructuring well. Merging during or after a move can be treacherous, however—it’s best if developers sync with the repository prior to moving things around. In summary, my rule of thumb is to plan for multiple streams of work in every repository. Even if the team doesn’t see a need now, it costs little and provides much in the way of flexibility and avoided pain.
Tags: tools