I\'m really confused. I want to do something that a) seems like it should be pretty simple, and b) other people must do all the time, but I cant find out the best w
I haven't tried this with an multiple repos myself, but I don't see why you can't use the suggestions from of your 2nd link.
svn merge ORIGINAL@REV UPGRADE@REV LOCAL_PATH
This effectively tells SVN to take all the changes between the original checkout and the version you want, and to apply them to your local copy.
Protip: I always use explicit revisions and include the merge command with the commit message, so that I can easily review the history and understand how to reproduce or undo changes.
I've just tried a brief experiment with TortoiseSVN:
Creating the test repositories
At this stage you will be in the state of having created your local 'branch' in a new repository. The last two steps are all you need for an existing project.
To simulate some changes to the original repo, modify the text file in co1 and commit the changes.
Merging Changes
Now, to create your own working copy, check out rep2 into co2.
We should be ready to try merging from rep1 into co2.
Open the merge dialog for co2 and point it at rep1.
For the 'from' revision select the revision at which you exported your copy (in this case revision 1), or the revision that you last updated your local copy to.
For the 'to' revision select the HEAD or the latest update you want to apply.
Results
This seems to work as expected, with the modifications from rep1 being applied to the working copy of rep2 in co2. These then need to be committed back to your local repository.
The vendor branches link you provided does effectively describe the process of what you want to do. It is a perfect solution relative to allowing you to do a straight update (import) of the vendor branch, and then as you allude to, will then allow you to merge the vendor's updates in with your changes in the main development branch.
The problem is that Subversion really doesn't provide direct support for file renames and moves of files between directories for the successive update from the vendor code because you are just getting snapshots of the source files' content....something needs to run the commands into the version system to indicate what changes are being made to the tree of file names that make up the new version. This is the purpose of the svn_load_dirs.pl script process. It helps you to get your version history manipulated around to match up the branches so that you can then proceed with the merge. If the vendor didn't rename and/or move files around between versions you imported, you would not have this problem.
In any case, the process described there is what you/need to do.