Subversion Notes
Vendor Branches

The official subversion documentation for managing vendor branches
describes the broad strokes of this particular workflow. However, it
doesn't go into enough detail about how one might "replace the code
in the current directory with the new [vendor] source code" [SB02].

Here's how I maintain vendor branches in my own repositories:

   1. In my example, I've stored the latest vendor source code in
   $VENDORLATEST. Per [SB02], this might come in the form of an
   extracted tarball.  However, it could also be the output of a cvs
   export or svn export operation (as is often the case if you're
   maintaining a private repository of some open source project).

   2. I have also checked out a clean working copy of my
   vendor/current (see [SB02] for more info on vendor/current) source
   tree to $WORKDIR.

   3. To apply the changes from $VENDORLATEST to $WORKDIR, I use
   rsync. This allows me to synchronize the directories while leaving
   the .svn/ metadata in $WORKDIR untouched. Here's an rsync command
   that would do this:

      rsync -av --exclude=.svn/ --delete $VENDORLATEST/ $WORKDIR

   4. The working copy should now contain the correct source code
   content. However, subversion is only aware of modified files. It
   still doesn't know what to do with newly added files or newly
   deleted files. Running the following commands in $WORKDIR should
   take care of that:

      for i in $(svn status | grep ? | cut -c 8-); do svn add $i; done

      for i in $(svn status | grep ! | cut -c 8-); do svn rm $i; done

   5. At this point, you should be able to commit the changes and svn
   copy to "tag" the vendor/current with the tagging convention of
   your choosing.

References

    * [SB01] Version Control with Subversion
    * [SB02] Version Control with Subversion - Vendor branches