Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 30956 invoked from network); 5 Jan 2011 09:56:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Jan 2011 09:56:57 -0000 Received: (qmail 55276 invoked by uid 500); 5 Jan 2011 09:56:57 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 55070 invoked by uid 500); 5 Jan 2011 09:56:56 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 55063 invoked by uid 99); 5 Jan 2011 09:56:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 09:56:56 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jan 2011 09:56:47 +0000 X-Envelope-From: stsp@stsp.name Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id p059uOpY012325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jan 2011 10:56:24 +0100 Received: from ted.stsp.name (stsp@localhost [127.0.0.1]) by ted.stsp.name (8.14.3/8.14.3) with ESMTP id p059uNaU014046; Wed, 5 Jan 2011 10:56:24 +0100 (CET) Received: (from stsp@localhost) by ted.stsp.name (8.14.3/8.14.3/Submit) id p059uNjG017643; Wed, 5 Jan 2011 10:56:23 +0100 (CET) Date: Wed, 5 Jan 2011 10:56:23 +0100 From: Stefan Sperling To: Nico Kadel-Garcia Cc: NN Ott , users@subversion.apache.org Subject: Re: Best way to maintain patches to a 3rd party library? Message-ID: <20110105095622.GA23722@ted.stsp.name> Mail-Followup-To: Nico Kadel-Garcia , NN Ott , users@subversion.apache.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 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 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.