From users-return-1260-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Mon Mar 01 09:47:04 2010 Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 93234 invoked from network); 1 Mar 2010 09:47:04 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Mar 2010 09:47:04 -0000 Received: (qmail 62936 invoked by uid 500); 28 Feb 2010 05:09:42 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 62924 invoked by uid 500); 28 Feb 2010 05:09:41 -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 62917 invoked by uid 99); 28 Feb 2010 05:09:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 05:09:41 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jeff.mott.or@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-px0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 05:09:34 +0000 Received: by pxi1 with SMTP id 1so294424pxi.16 for ; Sat, 27 Feb 2010 21:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tS6nOjnegeDxXQhQdNI+z9wFwHM+iy+qsvisrs6+S1c=; b=GGORG9pzavlVhpyDTsx0TkmBMpjqcEfTB2Dhha7XPwN4O1fI4zOOtSGUppF+3LEc21 YC1szBbAos0LOsAT+2ZxsMrgL85TyDGyH9SwMYYy810CofAg1UTtTP9HeV8QZBy6B478 gpNGOb0NANRrOemNcO85FCW5lRyD377gJLrQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oqjSvWKUnOlVDSxO3CDrtPKuC6wFglrDIbByUP4zv8OplU5uXiQprS9R0wBoBUmZGD DPYY432FN459tsAWZcNT20id+n+xPJQHVufJoIGm7DblGZI4MqJWsNIbEksSP9Hc4c38 8/hx0fwauNJg9tJR9JqdRiwm4zttmXuZfmcoM= MIME-Version: 1.0 Received: by 10.142.59.19 with SMTP id h19mr1522157wfa.243.1267333754518; Sat, 27 Feb 2010 21:09:14 -0800 (PST) In-Reply-To: References: <20100227120033.GB12141@noel.stsp.name> Date: Sat, 27 Feb 2010 21:09:14 -0800 Message-ID: Subject: Re: Managing Vendor Branches From: Jeff Mott To: Stefan Sperling Cc: users@subversion.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Feb 27, 2010 at 6:32 PM, Jeff Mott wrote: > On Sat, Feb 27, 2010 at 4:00 AM, Stefan Sperling wrote: >> On Fri, Feb 26, 2010 at 09:49:56PM -0800, Jeff Mott wrote: >>> I've recently needed to track changes for vendor code drops, so I read >>> the SVN book's vendor branches chapter. But I'm not entirely happy >>> with part of the procedure, so I'd like to talk it out and, I hope, >>> find a better way. >>> >>> The part I hope to improve is when I have a versioned code drop in the >>> /vendor directory, then the vendor provides a new code drop. The SVN >>> book suggests that I should copy the new files over top of the files >>> in my working copy. Then I need to SVN add and delete as needed. I saw >>> there's a script to ease this process, but I still feel that this >>> should be easier. >>> >>> It seems to me that comparing two trees, even unrelated trees, is >>> something SVN is very good at. >> >> In some way, yes. In some ways, no :) >> >> What it cannot do (and that is a major problem) is that it cannot >> reliably compare a working copy to a URL in the repository. >> It can however reliably compare URLs to URLs. >> >>> So if I have /vendor/code-drop-v1 and >>> /vendor/code-drop-v2, then it seems SVN should be able to derive the >>> changes between the two and apply those changes to my working copy. >>> >>> Can I do this? >> >> Yes, you can do a 2-URL merge: >> >> =A0cd working-copy >> =A0svn update # straighten potentially mixed-revision working copy >> =A0svn merge ^/vendor/code-drop-v1 ^/vendor-code-drop-v2 . >> >> This says "merge the difference between code-drop-v1 and code-drop-v2 >> into my working copy". >> The dot at the end is implied if you don't specify it. > > > This is exactly what I thought I could do. But what happens is that > SVN doesn't "update" the working copy files. Instead, it "replace"s > them. And when it tries to replace a file with customizations, that > creates a tree conflict. > > Is it supposed to work differently? Perhaps I'm doing something > wrong... I'd really like to figure this out because this can make my > life much easier. > > >> However, beware of renames the vendor made which affects files that >> you were modifying. Double-check that these files contain the correct >> content at their new location. >> >> Also note that importing a new vendor drop to a different URL than >> the old one will waste some disk space, unless you enable "rep-sharing" >> (see the file db/fsfs.conf in the repository). >> >> Stefan >> > I just discovered that using --ignore-ancestry fixed the problem. This caused SVN to update rather than replace my working copy.