Why should I use svn switch?
You might find this small treatise by Giovanni Bajo in python-dev on the svn switch command helpful: If you realize that each file/directory in Subversion is uniquely identified by a 2-space coordinate system [URL, revision] (given a checkout, you can use “svn info” to get its coordinates), then we can say that “svn up -r N” (for some revision number N) keeps the url unchanged and changes the revision to whatever number you specified. In other words, you get the state of the working copy URL at the time revision N was created. For instance, if you execute it with revision 39619 within the trunk working copy, you will get the trunk at the moment 2.4.2 was released. On the other hand, “svn switch” moves the URL: it basically “moves” your checkout from [old_URL, revision] to [new_URL, HEAD], downloading the minimal set of diffs to do so. If the new_URL is a tag URL (e.g. …/tags/r242), it means any revision is good, since nobody is going to commit into that directory (it will stay unchan
I found this small treatise by Giovanni Bajo in python-dev on the svn switch command helpful: If you realize that each file/directory in Subversion is uniquely identified by a 2-space coordinate system [URL, revision] (given a checkout, you can use “svn info” to get its coordinates), then we can say that “svn up -r N” (for some revision number N) keeps the url unchanged and changes the revision to whatever number you specified. In other words, you get the state of the working copy URL at the time revision N was created. For instance, if you execute it with revision 39619 within the trunk working copy, you will get the trunk at the moment 2.4.2 was released. On the other hand, “svn switch” moves the URL: it basically “moves” your checkout from [old_URL, revision] to [new_URL, HEAD], downloading the minimal set of diffs to do so. If the new_URL is a tag URL (e.g. …/tags/r242), it means any revision is good, since nobody is going to commit into that directory (it will stay unchanged for
