The Final Word on Merge Tracking
The bottom line is that Subversion’s merge-tracking feature has an
extremely complex internal implementation, and the svn:mergeinfo property is the only window the
user has into the machinery. Because the feature is relatively new, a
numbers of edge cases and possible unexpected behaviors may pop
up.
For example, sometimes mergeinfo will be generated when running a simple svn copy or svn move command. Sometimes mergeinfo will appear on files that you didn’t expect to be touched by an operation. Sometimes mergeinfo won’t be generated at all, when you expect it to. Furthermore, the management of mergeinfo metadata has a whole set of taxonomies and behaviors around it, such as “explicit” versus “implicit” mergeinfo, “operative” versus “inoperative” revisions, specific mechanisms of mergeinfo “elision,” and even “inheritance” from parent to child directories.
We’ve chosen not to cover these detailed topics in this book for a couple of reasons. First, the level of detail is absolutely overwhelming for a typical user. Second, as Subversion continues to improve, we feel that a typical user shouldn’t have to understand these concepts; they’ll eventually fade into the background as pesky implementation details. All that said, if you enjoy this sort of thing, you can get a fantastic overview in a paper posted at CollabNet’s web site: http://www.collab.net/community/subversion/articles/merge-info.html.
For now, if you want to steer clear of bugs and odd behaviors in automatic merging, the CollabNet article recommends that you stick to these simple best practices:
For short-term feature branches, follow the simple procedure described throughout Basic Merging.
For long-lived release branches (as described in Common Branching Patterns), perform merges only on the root of the branch, not on subdirectories.
Never merge into working copies with a mixture of working revision numbers, or with “switched” subdirectories (as described next in Traversing Branches). A merge target should be a working copy that represents a single location in the repository at a single point in time.
Don’t ever edit the
svn:mergeinfoproperty directly; use svn merge with the--record-onlyoption to effect a desired change to the metadata (as demonstrated in Blocking Changes).Always make sure you have complete read access to all of your merge sources, and that your target working copy has no sparse directories.