subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Mott <>
Subject Re: Managing Vendor Branches
Date Sun, 28 Feb 2010 05:09:14 GMT
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:
>>  cd working-copy
>>  svn update # straighten potentially mixed-revision working copy
>>  svn 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.

View raw message