Version Control with Subversion - Login

Branching and Mergingneed to question whether they have the right version of the vendor's data. They simply receivethat correct version as part of their regular working copy updates. Second, becausethe data lives in your own Subversion repository, you can store your custom changes to itin-place—you have no more need of an automated (or worse, manual) method for swappingin your customizations.General Vendor Branch Management ProcedureManaging vendor branches generally works like this: first, you create a top-level directory(such as /vendor) to hold the vendor branches. Then you import the third-party code intoa subdirectory of that top-level directory. You then copy that subdirectory into your maindevelopment branch (e.g., /trunk) at the appropriate location. You always make your localchanges in the main development branch. With each new release of the code you aretracking, you bring it into the vendor branch and merge the changes into /trunk, resolvingwhatever conflicts occur between your local changes and the upstream changes.An example will help to clarify this algorithm. We'll use a scenario where your developmentteam is creating a calculator program that links against a third-party complex number arithmeticlibrary, libcomplex. We'll begin with the initial creation of the vendor branch and theimport of the first vendor drop. We'll call our vendor branch directory libcomplex, and ourcode drops will go into a subdirectory of our vendor branch called current. And since svnimport creates all the intermediate parent directories it needs, we can actually accomplishboth of these steps with a single command:$ svn import /path/to/libcomplex-1.0 \http://svn.example.com/repos/vendor/libcomplex/current \-m 'importing initial 1.0 vendor drop'…We now have the current version of the libcomplex source code in /vendor/libcomplex/current. Now, we tag that version (see the section called “Tags”)and then copy it into the main development branch. Our copy will create a new directorycalled libcomplex in our existing calc project directory. It is in this copied version of thevendor data that we will make our customizations:$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \http://svn.example.com/repos/vendor/libcomplex/1.0 \-m 'tagging libcomplex-1.0'…$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \http://svn.example.com/repos/calc/libcomplex \-m 'bringing libcomplex-1.0 into the main branch'…We check out our project's main branch—which now includes a copy of the first vendordrop—and we get to work customizing the libcomplex code. Before we know it, our modifiedversion of libcomplex is now completely integrated into our calculator program. 7A few weeks later, the developers of libcomplex release a new version of their library—version1.1—which contains some features and functionality that we really want.We'd like to upgrade to this new version, but without losing the customizations we made tothe existing version. What we essentially would like to do is to replace our current baselineversion of libcomplex 1.0 with a copy of libcomplex 1.1, and then re-apply the custommodifications we previously made to that library to the new version. But we actually approachthe problem from the other direction, applying the changes made to libcomplexbetween versions 1.0 and 1.1 to our modified copy of it.7 And is entirely bug-free, of course!117