Vendor branches question

Hi,  I've been reading about vendor branches on http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html, and have a question. It all seems to make perfect sense to me, except for one bit:    

When you run svn_load_dirs.pl, it examines the contents of your existing “current” vendor drop and compares them with the proposed new vendor drop. In the trivial case, no files will be in one version and not the other, and the script will perform the new import without incident. If, however, there are discrepancies in the file layouts between versions, svn_load_dirs.pl will ask you how to resolve those differences. For example, you will have the opportunity to tell the script that you know that the file math.c in version 1.0 of libcomplex was renamed to arithmetic.c in libcomplex 1.1. Any discrepancies not explained by moves are treated as regular additions and deletions.

   I understand that if you're dealing with downloaded tarballs of libcomplex 1.0 and libcomplex 1.1 there is no revision history available, so this is a problem, but what if libcomplex were stored in a subversion repository itself? Couldn't you somehow use the revision history in the libcomplex repository (which knows about moves etc.) to create the diff and apply the changes to your customised version?    It seems that the complexities with vendor branches shouldnt be a problem if both the 3rd party code and your own code is stored in subversion repositories. Is there an alternative way to do vendor branching in this situation?    Thanks,  Jack

Last updated 14 years ago

If you're only using release versions of libcomplex, then the "internal" history between 1.0 and 1.1 shouldn't really be needed in your repository. Using vendor branches as described in the fine manual should be sufficient - you'll have a history of the differences between those 2 releases.    If libcomplex is from another repository, you can use svn:externals to pull in the code from that repository instead of copying it to yours.

Sorry, I'm now more confused.    There's an external repository that contains some 3rd party code. I take a copy of version 1 of the code and put it in my own repository, I then customise it for my own needs. When version 2 of that code is released I want to be able to upgrade my customised version with all of the version 2 changes, retaining my customisations.    It was my understanding that vendor branches were the solution to this, however in the instructions for vendor branches in the book it says that when a file is moved or renamed from version 1 to version 2 of the 3rd party code you need to manually tell it those changes were made (as per the quote in my first post).    What I don't understand is why that is necessary if the 3rd party code is also stored in a repository, given that all the information needed to tell what files have been renamed or moved is known. Why cant I just go to the 3rd party repository, get a diff of version 1 vs version 2 and the apply that to my customised version?    Thanks,  Jack

No risk in trying it. I think new files may not be represented in the patch; there's some little oddity with things either not being in the patch format, or not being supported by GNU patch when applied, but I don't recall the details.

You could. The only problem is that the current diff format is not capable of describing everything that can happen to a source tree. See here: http://subversion.tigris.org/tasks.html#customizable-diff    It should be possible to create a program that mirrors the commits of one repository into a branch on another. This would be best way I can think of to do a vendor branch strategy with subversion. I'm not clear on whether such a program exists though. This is just one of those cases where decentralized version control really shines out.

I've discovered that in 1.5 you can actually perform merges across different repos, so that solves my problem entirely.    Thanks for all you help,  Jack

Jak-SI've discovered that in 1.5 you can actually perform merges across different repos, so that solves my problem entirely.

I don't know if that was advertised as a feature - it may be a bug, and if it is, don't count on it working in future releases.

Yeah, it is a kind-of undocumented/unintentional feature, but people seem to be working on it (http://blogs.open.collab.net/svn/2008/03/do-not-post-mer.html), I'll just keep my fingers crossed that it keeps working, given that it's so useful I'm sure other people would support keeping it in. Also, it is kind of half mentioned in the SVN Book.