Version Control with Subversion - Login

Branching and Merging$ svn propget svn:mergeinfo ./trunk:341-349,355# Notice that r355 isn't listed as "eligible" to merge, because# it's already been merged.$ svn mergeinfo ^/trunk --show-revs eligibler350r351r352r353r354r356r357r358r359r360$ svn merge ^/trunk--- Merging r350 through r354 into '.':U .U integer.cU Makefile--- Merging r356 through r360 into '.':U .U integer.cU button.cThis use case of replicating (or backporting) bug fixes from one branch to another is perhapsthe most popular reason for cherrypicking changes; it comes up all the time, for example,when a team is maintaining a “release branch” of software. (We discuss this patternin the section called “Release Branches”.)Did you notice how, in the last example, the merge invocation caused two distinctranges of merges to be applied? The svn merge command applied twoindependent patches to your working copy to skip over changeset 355, whichyour branch already contained. There's nothing inherently wrong with this, exceptthat it has the potential to make conflict resolution trickier. If the first rangeof changes creates conflicts, you must resolve them interactively for the mergeprocess to continue and apply the second range of changes. If you postpone aconflict from the first wave of changes, the whole merge command will bail outwith an error message. 4A word of warning: while svn diff and svn merge are very similar in concept, they do havedifferent syntax in many cases. Be sure to read about them in Chapter 9, Subversion CompleteReference for details, or ask svn help. For example, svn merge requires a workingcopy path as a target, that is, a place where it should apply the generated patch. If the targetisn't specified, it assumes you are trying to perform one of the following common operations:• You want to merge directory changes into your current working directory.• You want to merge the changes in a specific file into a file by the same name that existsin your current working directory.If you are merging a directory and haven't specified a target path, svn merge assumes thefirst case and tries to apply the changes into your current directory. If you are merging afile, and that file (or a file by the same name) exists in your current working directory, svnmerge assumes the second case and tries to apply the changes to a local file with thesame name.4 At least, this is true in Subversion 1.5 at the time of this writing. This behavior may improve in future versions ofSubversion.101