On Sat, Feb 27, 2010 at 4:00 AM, Stefan Sperling <s...@elego.de> 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 >