Version Control with Subversion - Login

Branching and Merging$ cd calc/trunk$ svn merge --reintegrate ^/branches/my-calc-branch--- Merging differences between repository URLs into '.':D integer.cA whole.cU .This doesn't look so bad at first glance, but it's also probably not what you or Sally expected.The merge operation has deleted the latest version of the integer.c file (the onecontaining Sally's latest changes), and blindly added your new whole.c file—which is aduplicate of the older version of integer.c. The net effect is that merging your “rename”to the branch has removed Sally's recent changes from the latest revision!This isn't true data loss. Sally's changes are still in the repository's history, but it may notbe immediately obvious that this has happened. The moral of this story is that until Subversionimproves, be very careful about merging copies and renames from one branch to another.Blocking Merge-Unaware ClientsIf you've just upgraded your server to Subversion 1.5 or later, there's a significant risk thatpre-1.5 Subversion clients can mess up your automated merge tracking. Why is this?When a pre-1.5 Subversion client performs svn merge, it doesn't modify the value of thesvn:mergeinfo property at all. So the subsequent commit, despite being the result of amerge, doesn't tell the repository about the duplicated changes—that information is lost.Later on, when “merge-aware” clients attempt automatic merging, they're likely to run intoall sorts of conflicts resulting from repeated merges.If you and your team are relying on the merge-tracking features of Subversion, you maywant to configure your repository to prevent older clients from committing changes. Theeasy way to do this is by inspecting the “capabilities” parameter in the start-commithook script. If the client reports itself as having mergeinfo capabilities, the hook scriptcan allow the commit to start. If the client doesn't report that capability, have the hook denythe commit. We'll learn more about hook scripts in the next chapter; see the section called“Implementing Repository Hooks” and start-commit for details.The Final Word on Merge TrackingThe bottom line is that Subversion's merge-tracking feature has an extremely complex internalimplementation, and the svn:mergeinfo property is the only window the user hasinto the machinery. Because the feature is relatively new, a numbers of edge cases andpossible unexpected behaviors may pop up.For example, sometimes mergeinfo will be generated when running a simple svn copy orsvn move command. Sometimes mergeinfo will appear on files that you didn't expect to betouched by an operation. Sometimes mergeinfo won't be generated at all, when you expectit to. Furthermore, the management of mergeinfo metadata has a whole set of taxonomiesand 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 Subversioncontinues 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 thatsaid, if you enjoy this sort of thing, you can get a fantastic overview in a paper posted atCollabNet's website: http://www.collab.net/community/subversion/articles/merge-info.html.108