subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Best way to maintain patches to a 3rd party library?
Date Wed, 05 Jan 2011 09:56:23 GMT
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 <nonot100@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.

Mime
View raw message