
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Vendor Branches
|
159
code is under version control. Oh, and we want to do this with as little version con-
trol history disturbance as possible.
After replacing the 1.0 code with 1.1 code,
svn status will show files with local mod-
ifications as well as, perhaps, some unversioned or missing 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—we run
svn add on those to get them under version con-
trol. The missing files are files that were in 1.0 but not in 1.1, and on those paths we
run
svn remove. 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 (in
the same way we previously tagged the version 1.0 vendor drop), and then merge the
differences between the tag of the previous version and the new current version into
our main development branch.
$ cd working-copies/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/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, ...