Re: Managing Vendor Branches

On Feb 26, 2010, at 23:49, 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. 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?

I think you may be confusing two different things. First, there the matter of getting the remote code into your local Subversion repository as-is. Second, there's the matter of making a branch of that vendor code that you will modify locally. These are both necessary and two separate things.

For getting the remote vendor code into your own repository, the book addresses taking a tarball and using "svn import" to get it into your repository, and then using copy-on-top in a working copy to keep it updated later. The svn_load_dirs.pl script you mention is an easier way to keep the vendor software updated in your repository. I have just been informed that an even easier way is to simply "svn merge" the relevant changes from the remote repository into your own, assuming the vendor manages their software in Subversion too. For more information on this latest development please see:

http://svn.haxx.se/users/archive-2010-02/0226.shtml

The second issue is making a copy of that vendor code and making local changes to it. The key point to realize is that the vendor's code in /vendor in your repository shall be pristine -- you are not to make any changes here, except to update it to a later version of the vendor's software. If you want to make your own changes to their software, you must first copy a specific version of it to some place in your repository outside of /vendor. Let's say you are tracking the code for MySQL and need to maintain local changes to it. You'd have /vendor/mysql/current which represents an unaltered copy of MySQL's source code from, let's say, version 5.1.44, which you've brought in using "svn import". You'll probably also copy /vendor/mysql/current to /vendor/mysql/5.1.44 as a sort of tag. To make changes, you'll copy /vendor/mysql/5.1.44 to let's say /mysql in the same repo. Then you can modify /mysql to your heart's content. Later, when MySQL AB releases version 5.1.45, you'll want to do two things: First, you'll want to update the pristine copy in /vendor/mysql/current. To do this, you can do it the book way: check out a working copy of /vendor/mysql/current, untar the 5.1.45 tarball on top of it, deal with svn add's and svn delete's, and commit. Or, you can use svn_load_dirs.pl to do this for you. Or you can "svn merge" the changes from MySQL AB's repository's 5.1.44 tag to their 5.1.45 tag into a working copy of /vendor/mysql/current (assuming they use a Subversion repository; I can't find out if they do). Whatever method you use, you'll also make a new tag by copying /vendor/mysql/current to /vendor/mysql/5.1.45. Now that you've updated your untouched copy of their code in /vendor/mysql, you can "svn merge" the changes from /vendor/mysql/5.1.44 to /vendor/mysql/5.1.45 into a working copy of your /mysql area to update your version.

Given the new developments C. Michael Pilato mentioned, perhaps we can dispense with the whole first part of this (i.e. dispense with having a /vendor directory at all) and exclusively merge from the remote upstream repository. If they also use Subversion. I haven't had occasion to try this new method yet. But it would certainly simplify things.
Received on 2010-02-27 13:28:59 CET