I’ve had the pleasure of participating in two recent webinars on the topic of branching and merging particularly in the context of the pending 1.5 release with merge tracking. The first webinar, entitled "Branching and Merging Strategies for Subversion 1.5", focused on three branch and merge models. The second, "Advanced Merge Tracking and Branching with Subversion 1.5", focused on questions from the audience of the first webinar. The intent of both was to provide some practical information on a topic that has great importance in enterprises, but isn’t well covered by what’s generally available around Subversion.
I wanted to post some of the questions and answers that I covered in the second webinar here in our blog. I hope that they will be useful and I encourage you to view the replays of the webinars to learn more (http://www.collab.net/webinar21 and http://www.collab.net/webinar22).
If installing a 1.5 server, is there a way to have the server reject 1.4 clients to guarantee merge tracking?
A potential proposal is being discussed for the development of a pre-commit hook to be able to reject commits from pre-1.5 clients. This is still under discussion so it is not available nor even guaranteed to be produced. I suggest that those interested make their interest known on the users.subversion.tigris.org mailing list. In general though, this scenario normally requires a human process as well as the server upgrade in order to be sure you are in an environment where the feature is accessible and utilized by all users. The Subversion community makes upgrading the server and the client straightforward by guaranteeing that point releases (like 1 point 5) are not disruptive. In situations where you want to assure yourself that new functionality is used uniformly, you have to supplement the upgrade with human processes. That is the answer for merge tracking if a hook is not provided.
Are full copies of each file revision kept in the repository?
No, Subversion uses a binary delta algorithm to identify and store only deltas between revisions. That’s the easy answer, but there’s always more to the story. Subversion uses a skip-delta approach in order to provide quick access to every revision of a file. Skip-delta is a technique that ensures that only a reasonable number of deltas need to be composed in order retrieve any revisions of a file. It is a bit complicated to explain so if you’re interested in the skip delta implementation, please read the oficial documentation for it (a summary is in the March ’07 openCollabNet Technical Newsletter).
Do you have a strategy for capturing nightly release snapshots for testing?
I think that the use of either revision numbers or a date and time is appropriate for what is a fleeting need of identifying a specific snapshot for such a build. Tags should be used when others will potentially need to be able to trace a build to source or even if you need that yourself in the future.
Are third party tools needed to fully leverage the new merge tracking functionality?
The short answer is "no" as the functionality is realized through the standard operations of merge, log and blame. That said, there is certainly the potential to utilize the core functionality in more user friendly or broader solutions. To that end, we added specific functionality to our CollabNet Desktop – Eclipse Edition to help with merge management and to tie it to named change sets. I would expect other extensions coming from the addition of the merge tracking functionality moving forward.
That somewhat leads me into a follow-up question: "Is there a concept of change sets and can you merge based on them?"
A fundamental feature of Subversion comes from the atomic commit defining a change set with a specific revision number identifying the commit and resulting change set. Merge tracking provides the ability to cherry pick a specific revision as a source for a merge and thus merge the specific change set associated with that revision to your target branch. If the desired change set isn’t confined to a single revision, then a solution may require an association with issue management where the change set is linked to an issue and a tool like the CollabNet Change Set Merge can be used with CollabNet/SourceForge Enterprise Edition.
Can you provide a high-level comparison of what is available today in the svnmerge client and what will be in 1.5 core functionality?
In general, 1.5 provides broader support for the features it has in common with svnmerge.py. Some svnmerge.py features, like revision blocking for example, will come in future releases of Subversion and are not present in 1.5. The broader support of 1.5 features is seen in:
- Support of per-path versus branch-level granularity.
- Merging changes to the svn:mergeinfo property as subsequent merges or changes are made.
- Support from common clients versus having to be used outside of those clients. This will also give us more comprehensive auditing tools.
Will 1.5 merge tracking be able to use svnmerge.py data?
A migration script is being provided with 1.5 that will allow you to migrate the svnmerge data into the new core solution. This script facilitates the conversion of migration data from the client-side approach of svnmerge into the core solution. A user can chose to execute the migration across an entire repository or selectively across specific paths. This means that you can use svnmerge today to ease the burden of manually tracking merges and be able to carry that data forward so that effectively merge tracking can be audited even for merges made prior to the release and installation of 1.5.
I’ll give you a chance to at least listen to a replay of the first webinar before I post some of the questions and answers relating to the three basic branching strategies discussed.