When one does svn switch <source> <target>, I understand that it switches the working directory to target path.
I would like to understand what --relocate is used for. I thought this was only used when the url of repository had changed and one wanted to update working copy url to point to new svn server location. But it seems Relocate can only change the repository part of an URL.
So my question is, what does the --relocate switch do? In particular, can it be used to integrate to user branch a vendor branch that has many differences since previous version, ie
svn co path\to\vendor\lib
svn --relocate lib url\path\to\my\branch
svn commit -m "Updated my branch with vendor code without using cp, this way _I think_ enables deleting folders and files that don't exist in new version of vendor lib.
Am I getting any of this right?
SVN Relocate is for when those pesky admins move the path to your repository.
For example original:
http://mydomain.com/svn/repo/Project/MyApplication/trunk
Admin gets bored and changes it to:
http://mydomain.com/svn/MyApplication/trunk
You would need to do svn relocate to tell svn that the path to your project has changed.
As for your provided example it can not be used to reintegrate branches, the command is to let the svn client update all of its paths to the new location of your repository. You need to svn merge them.
I thought this was only used when the url of repository had changed and one wanted to update working
copy url to point to new svn server location.
That is exactly what it does. If your the subversion server has changed its location, use "switch --relocate", it will just contact the server and chack if its still there, and then rewrite the URLs in your working copy to the new URL. Your working copy isn't updated with any differences from the server (until you run svn update again)
svn switch, without the --relocate switches your working copy to a new location (typically a branch) and makes whatever changes needed to your working copy to transform it into that branch It's pretty much the same as just checking out that branch, but usually faster and more convenient.
More info here/here
In particular, can it be used to integrate to user branch a vendor branch that has many differences
since previous version, ie
No, that's what svn merge is for.
Although svn switch could allow you to test out that vendor branch in your working copy first. You keep your main project as it used to, but you switch the subdirectory where the vendor stuff is to the new vendor branch.
Note that subversion does not (yet) support any merging/brancing between different subversion servers, so your vendor branch have to be imported into the server where your "user branch" is first. Then you could merge that new vendor branch with your user branch.
You could use svn:external for this too, it's common to keep vendor code outside your project path, and "import" them in a working copy using svn:external. e.g. you have
/myproject/trunk/ as your project and /3party/libraryFoo/version1/
When working with myproject you want to have it under /myproject/trunk/libraryFoo so you just add an svn:external on /myproject/trunk/ to e.g. libraryFoo http://myserverver//3party/libraryFoo/version1/ . When you want to update to a new version ,you just change the svn:external to e.g. libraryFoo http://myserverver//3party/libraryFoo/version2 . This allows you to pull in stuff from another subversion server as well, e.g. directly to the 3.party subersion server - though that's not very useful if you intend to make local changes.
