Version Control with Subversion - Login

Branching and Mergingyou've been doing up until now. Previously, we had been asking svn merge to grab the“next set” of changes from one line of development (the trunk) and duplicate them to another(your branch). This is fairly straightforward, and each time Subversion knows how topick up where it left off. In our prior examples, you can see that first it merges the ranges345:356 from trunk to branch; later on, it continues by merging the next contiguously availablerange, 356:380. When doing the final sync, it merges the range 380:385.When merging your branch back to the trunk, however, the underlying mathematics is quitedifferent. Your feature branch is now a mishmosh of both duplicated trunk changes andprivate branch changes, so there's no simple contiguous range of revisions to copy over.By specifying the --reintegrate option, you're asking Subversion to carefully replicateonly those changes unique to your branch. (And in fact, it does this by comparing the latesttrunk tree with the latest branch tree: the resulting difference is exactly your branchchanges!)Now that your private branch is merged to trunk, you may wish to remove it from the repository:$ svn delete ^/branches/my-calc-branch \-m "Remove my-calc-branch."Committed revision 392.But wait! Isn't the history of that branch valuable? What if somebody wants to audit theevolution of your feature someday and look at all of your branch changes? No need toworry. Remember that even though your branch is no longer visible in the /branches directory,its existence is still an immutable part of the repository's history. A simple svn logcommand on the /branches URL will show the entire history of your branch. Your branchcan even be resurrected at some point, should you desire (see the section called“Resurrecting Deleted Items”).In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, thebranch is no longer usable for further work. It's not able to correctly absorb new trunkchanges, nor can it be properly reintegrated to trunk again. For this reason, if you want tokeep working on your feature branch, we recommend destroying it and then re-creating itfrom the trunk:$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \-m "Remove my-calc-branch."Committed revision 392.$ svn copy http://svn.example.com/repos/calc/trunk \http://svn.example.com/repos/calc/branches/new-branch-m "Create a new branch from trunk."Committed revision 393.$ cd my-calc-branch$ svn switch ^/branches/new-branchUpdated to revision 393.The final command in the prior example—svn switch—is a way of updating an existingworking copy to reflect a different repository directory. We'll discuss this more in the sectioncalled “Traversing Branches”.Mergeinfo and PreviewsThe basic mechanism Subversion uses to track changesets—that is, which changes havebeen merged to which branches—is by recording data in properties. Specifically, mergedata is tracked in the svn:mergeinfo property attached to files and directories. (If you'renot familiar with Subversion properties, now is the time to skim the section called95