HowTo? Modified vendor code, and, vendor releases new version

Say I have version 1.0 of vendor code. I keep a vendor branch, and, tag it. I now modify that code in trunk, and, save it. So, I have a modified version 1.0. It runs for a while, and now version 2.0 of the vendor code comes out. What is the correct SmartSVN method of handling this? What I want to do is to take the changes the vendor made, and, apply them (perhaps with some exceptions of course) to my modified version.    I have tried a merge from two sources, old vendor and new vendor, but that leaves all sorts of extra files around that are not in the vendor 2.0 code, but, were in vendor 1.0 code. Amongst other issues. So, I presume this is the wrong way.    I just don't know the best way to do this in SmartSVN.

Last updated 8 years ago

I'm not sure how many files you're talking about here but it sounds like you might be better having version 2 of the vendor software in a separate repository (or branch) and adding what you need from that to your trunk manually - depending on the changes you want.  If you don't want a lot of the v1 files left after the merge you'll either need to exclude those in the first place or remove them after the merge manually I'm afraid.

orbrey;168580I'm not sure how many files you're talking about here but it sounds like you might be better having version 2 of the vendor software in a separate repository (or branch) and adding what you need from that to your trunk manually - depending on the changes you want.    If you don't want a lot of the v1 files left after the merge you'll either need to exclude those in the first place or remove them after the merge manually I'm afraid.

   Couldn't tell you which files were changed, I thought that's what SVN was for? Probably, 3,000 file or so in the vendor code, some unknown number of which I changed. The requirement here is not to start with our modified code, but, to start with the new vendor code and apply any changes we made to it. What we need to get out of this is new modified v2 code. To do that, it's nice to know what files went away, what files we changed, what files are new and might need to be looked into. Isn't that what a version control system is for? This is a very common issue with open source code. Are you saying there is no good solution?

Right, okay - to be honest I'm still trying to figure out what you're wanting to do.  When you get version 2 of this code, are you checking this out from another repository? If so you'll have the log of all the changes the developers made to it. Either way, just to make sure - is it that you want to compare this to your own code from the v1 tag and then merge the two?

Searching the net, one of the terms used is vendor branching. I used to have it working with SmartSVN 5 and 6, but, appears different now, not sure why, terminology is different too, might be just doing something wrong. The while purpose of this is to have Subversion tell me, not to check myself. While this project has only a few thousand files, another project I work on has close to one hundred thousand files. Obviously, I am not going to look at their log to figure out what they changed. Nor would I want to manually integrate their changes.  If the vendor has say a nice round 100,000 source files, and, I change 100 of them, obviously, I want to take my changes and add them to their source, not the other way.   if you are not familiar with vendor branching, you cannot help me, it's too hard to explain. I will have to just keep trying different techniques in SmartSVN until I can get it to work.

I've been having a read through the red bean book which has a chapter on vendor control - apologies if you've seen it already, but the chapter here: http://svnbook.red-bean.com/en/1.1/ch07s05.html describes pretty much your scenario.  It'd definitely be worth a read if you haven't, but in summary:  Copy vanilla v2 code into a copy of your vanilla v1 code directory, overwriting all files. Run svn status to see the changed files, along with any unversioned and/or missing. Run svn add on all the unversioned files to make sure they're added (those should all be from v2) Run svn delete on all the missing files left over from v1 Commit and tag the new folder which should now contain the v2 code.  Then merge the differences between your v1 tag and your v2 tag into your main development folder (I believe you said this was in the trunk?)   If the code structure hasn't changed too much between v1 and v2 that should be fine, otherwise things get more complicated and I'll defer to the red-bean chapter on that score. I hope that helps though.