[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Best way to maintain patches to a 3rd party library?

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 5 Jan 2011 10:56:23 +0100

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_at_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.
Received on 2011-01-05 10:57:05 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.