svn vendor branch

Question

In the svn red book, in the chapter "Vendor Branch", it is proposed to maintain a current/ containing the latest release of 3rd party product, so from the example we end up with:

   repos/vendor/libcomplex/current - contains 1.1
   repos/vendor/libcomplex/1.0
   repos/vendor/libcomplex/1.1 

What is it purpose of current/? Why we need initially put a new version to current/ and only after that to copy current/ in a version dedicated directory (e.g. 1.1)?

My guess it's for:

1. To make different versions svn comparable.
2. As a side the version are stored in more efficient way in svn repository.

Can I bypass handling of current/ in vendor branch?

Update: I don't intend to patch the vendor code (at least this is a plan). So I'm going to use svn:external to use an appropriate vendor version drop.

Answer 1

It is needed because using the svn_load_dirs.pl script you destroy contentes of this dir and import everything as new.

No you can't bypass it, as it is necessary and useful.

The point is in deleted dirs and files in the new vendor drop respect to the old one. This script handles this importing the new vendor drop into current and then removing by "automated hand" every no more existant file/dir. Then merge.

svn_load_dirs.pl

Vendor drops that contain more than a few deletes, additions and moves complicate the process of upgrading to each successive version of the third-party data

Answer 2

In addition to AlberT's comments, having a dedicated directory (current) also helps to have a constant path reference if your build scripts are goign to reference an area where you should see the latest vendor code ALWAYS.

Answer 3

The intent of that vendor branch management scheme is to put the releases of the 3rd party product into your repository such that you establish a history between releases. If you simply import release 1.0 to repos/vendor/libcomplex/1.0 and import release 1.1 to repos/vendor/libcomplex/1.1, there will be no history in Subversion between releases 1.0 and 1.1, and you will not be able to view the changes between release 1.0 and 1.1 in Subversion. Sure, you can checkout both and use GNU diff to compare them, but you are not taking advantage of the power of Subversion in that case.

The history is important if you are creating your own branch and wish to merge the changes between 1.0 and 1.1 into your branch. The history is also import if you wish to view the changes in Subversion between releases 1.0 and 1.1. Finally, having a history results in a more efficient storage of the data, because only the delta between 1.0 and 1.1 is stored.

By importing release 1.0 to repos/vendor/libcomplex/current and then adding release 1.1 to that same directory, you establish a history between 1.0 and 1.1.

Answer 4

Using a /vendor/current branch makes the /vendor/tag branches pure shadow copies.

I have also used the current branch for very minor releases in between a vendor's major releases, where I do not see a need to add a tag.