On Tue, Jan 04, 2011 at 09:20:52PM -0500, Nico Kadel-Garcia wrote: > On Tue, Jan 4, 2011 at 6:35 PM, NN Ott <nonot...@gmail.com> wrote: > > Hello, > > > > I have a source library that I need to periodically import (and then patch) > > for use by my code base. > > > > The SVN Book seems to reccomend a "vendor branch" scheme where you keep a > > patched branch of the "vendor drops". This would work, except that I loose > > any history of the library development. (The vendor also uses SVN and gives > > read-only access to their repo.) > > You drop the vendor branch download on top of a copy of the old > branch, using something like this: > > > svn copy svn://repo/tags//vendor-1.0 svn://repo/branches/vendor-2.0-merge > scn co svn://repo/branches/vendor/2.0-merge 2.0-merge > > tar xzvf vendor-2.0.tar.gz > rsync -avH --exclude=.svn --delete vendor.2.0/ 2.0-merge/ > cd 2.0 > svn status > [ Add necessary files, delete missing files, set whatever svn > properties you need, etc. etc.
The above steps can also semi-automated using svn_load_dirs: https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs Stefan > > svn commit > svn copy. svn://repo/tags/vendor-2.0 > > Delete svn://repo/branches/vendor-2.0-merge if you feel so inclined. > > This will combine the forced upgrade into a single commit. Don't do > *ANY* other work in those branches and tags. > > You can then try to merge that tag with your trunk or other branches, > although SVN merges are not their strongest feature.
