Version Control with Subversion - Login

Branching and Mergingreason, it's easy to think of revision N as not just a tree, but a changeset as well. If you usean issue tracker to manage bugs, you can use the revision numbers to refer to particularpatches that fix bugs—for example, “this issue was fixed by r9238.” Somebody can thenrun svn log -r 9238 to read about the exact changeset that fixed the bug, and run svndiff -c 9238 to see the patch itself. And (as you'll see shortly) Subversion's svn mergecommand is able to use revision numbers. You can merge specific changesets from onebranch to another by naming them in the merge arguments: passing -c 9238 to svnmerge would merge changeset r9238 into your working copy.Keeping a Branch in SyncContinuing with our running example, let's suppose that a week has passed since you startedworking on your private branch. Your new feature isn't finished yet, but at the sametime you know that other people on your team have continued to make important changesin the project's /trunk. It's in your best interest to replicate those changes to your ownbranch, just to make sure they mesh well with your changes. In fact, this is a best practice:frequently keeping your branch in sync with the main development line helps prevent“surprise” conflicts when it comes time for you to fold your changes back into the trunk.Subversion is aware of the history of your branch and knows when it divided away from thetrunk. To replicate the latest, greatest trunk changes to your branch, first make sure yourworking copy of the branch is “clean”—that it has no local modifications reported by svnstatus. Then simply run:$ pwd/home/user/my-calc-branch$ svn merge ^/trunk--- Merging r345 through r356 into '.':U button.cU integer.cThis basic syntax—svn merge URL—tells Subversion to merge all recent changes fromthe URL to the current working directory (which is typically the root of your working copy).Also notice that we're using the carat (^) syntax 2 to avoid having to type out the entire /trunk URL.After running the prior example, your branch working copy now contains new local modifications,and these edits are duplications of all of the changes that have happened on thetrunk since you first created your branch:$ svn statusM .M button.cM integer.cAt this point, the wise thing to do is look at the changes carefully with svn diff, and thenbuild and test your branch. Notice that the current working directory (“.”) has also beenmodified; the svn diff will show that its svn:mergeinfo property has been either createdor modified. This is important merge-related metadata that you should not touch, since itwill be needed by future svn merge commands. (We'll learn more about this metadatalater in the chapter.)After performing the merge, you might also need to resolve some conflicts (just as you dowith svn update) or possibly make some small edits to get things working properly.(Remember, just because there are no syntactic conflicts doesn't mean there aren't any semanticconflicts!) If you encounter serious problems, you can always abort the local2 This was introduced in svn 1.6.92