tags:

views:

942

answers:

3

What is a best practice when setting up subversion to use vendor branches? our repository is structured for individual projects. We are using subversion 1.6.2 and tortoisesvn 1.6.3

example:
Project1
/tags
/branches
/trunk

Project2
/tags
/branches
/trunk

1)Where would I put the vendors folder and what structure should it have? 2)Is there an example using the tortoisesvn client?

+5  A: 

The Subversion manual has a section specifically on Vendor Branches.

The basic idea is you import the current release, unmodified, into the repository via a set of folders which track the external changes (just the external changes, not your modifications to it). Something like ".../repos/vendor/(software)/current". Then branch right away into ".../repos/vendor/(software)/(software-version)". As new releases come out, update the "current" directory and create a new branch, such as ".../repos/vendor/(software)/(next-version)". This lets you (and svn) do diffs on the unmodified source to arrive at what changed externally.

For your modifications to the software, branch the "(software-version)" into your own project, something like ".../repos/(my-project)/trunk/(software)". When you upgrade to the next version of the 3rd party source, tell svn to merge the difference between "(software-version)" and "(next-version)" into a working copy of "trunk/(software)". This pulls all external changes into trunk, neatly upgrading the project source. Branch and tag the project as normal.

The Subversion distro includes a Perl script called "svn_load_dirs.pl", which can help when upgrading the "vendor" project. It discovers deleted, added, and renamed files and modifies your working copy of, for example "(current)", as appropriate.

James Hugard
That damn SVN book has everything, doesn't it?
T Pops
A: 

What you say is true but in practice you will see a very big problem.

When you import the vendor project into your subversion repository (and supose the vendor project it's a big one let's say like apache httpd 2.2) you will find that it is impossible to import the svn:ignore properties on each directory due to the fact that there does not exist any export tool that can do this only with access to WebDAV interface (there is svn admin tool that can export svn props but requires direct access on vendor repository).

So when you import a vendor project you will have to export first the original one from vendor svn repository and after importing the files into your svn you will set the svn props manually for every directory inside the project. A very paintfull method but is the only one if you really want to modify the vendor project and keep up with their modifications.

gigiduru
A: 

By the way the Perl script called "svn_load_dirs.pl" is totaly inefficient since it does not know about the svn props. After running such a script again you will have to manually set svn props and commit again and only after this step you can create the tag version copy. Nice isn't it?

gigiduru