Version Control with Subversion - Login

Branching and MergingTo perform this upgrade, we check out a copy of our vendor branch and replace the codein the current directory with the new libcomplex 1.1 source code. We quite literally copynew files on top of existing files, perhaps exploding the libcomplex 1.1 release tarball atopour existing files and directories. The goal here is to make our current directory containonly the libcomplex 1.1 code and to ensure that all that code is under version control. Oh,and we want to do this with as little version control history disturbance as possible.After replacing the 1.0 code with 1.1 code, svn status will show files with local modificationsas well as, perhaps, some unversioned files. If we did what we were supposed to do,the unversioned files are only those new files introduced in the 1.1 release of libcomplex—werun svn add on those to get them under version control. If the 1.1 code no longerhas certain files that were in the 1.0 tree, it may be hard to notice them; you'd have to comparethe two trees with some external tool and then svn delete any files present in 1.0 butnot in 1.1. (Although it might also be just fine to let these same files live on in unused obscurity!)Finally, once our current working copy contains only the libcomplex 1.1 code,we commit the changes we made to get it looking that way.Our current branch now contains the new vendor drop. We tag the new version as 1.1(in the same way we previously tagged the version 1.0 vendor drop), and then merge thedifferences between the tag of the previous version and the new current version into ourmain development branch:$ cd working-copies/calc$ svn merge ^/vendor/libcomplex/1.0 \^/vendor/libcomplex/current \libcomplex… # resolve all the conflicts between their changes and our changes$ svn commit -m 'merging libcomplex-1.1 into the main branch'…In the trivial use case, the new version of our third-party tool would look, from a filesand-directoriespoint of view, just like the previous version. None of the libcomplex sourcefiles would have been deleted, renamed, or moved to different locations—the new versionwould contain only textual modifications against the previous one. In a perfect world, ourmodifications would apply cleanly to the new version of the library, with absolutely no complicationsor conflicts.But things aren't always that simple, and in fact it is quite common for source files to getmoved around between releases of software. This complicates the process of ensuring thatour modifications are still valid for the new version of code, and things can quickly degradeinto a situation where we have to manually re-create our customizations in the new version.Once Subversion knows about the history of a given source file—including all its previouslocations—the process of merging in the new version of the library is pretty simple.But we are responsible for telling Subversion how the source file layout changed fromvendor drop to vendor drop.svn_load_dirs.plVendor drops that contain more than a few deletes, additions, and moves complicate theprocess of upgrading to each successive version of the third-party data. So Subversionsupplies the svn_load_dirs.pl script to assist with this process. This script automates theimporting steps we mentioned in the general vendor branch management procedure tomake sure mistakes are minimized. You will still be responsible for using the merge commandsto merge the new versions of the third-party data into your main developmentbranch, but svn_load_dirs.pl can help you more quickly and easily arrive at that stage.In short, svn_load_dirs.pl is an enhancement to svn import that has several importantcharacteristics:118