2008/5/24 Jens Seidel <jensseidel@users.sf.net>:
Calling "svn up" from the current directory would update all subdirectories. So release/ would be deleted and release_last/ created. After this the new release/ is fetched.
But that's assuming that you have the branches directory checked out, if you don't then the following case applies:
If "svn up" is called from inside release/ nothing would happen, as the content of this directory (with URL .../release_last@HEAD) was not changed.
but would the URL be release_last@HEAD? I don't think subversion would update the working url in this case? I don't think it would in this case without doing a switch or switch --relocate (at least not with versions <= 1.4 I don't know about 1.5). I don't really find renaming obscure, its just that I think that subversion is just rather bad at dealing with it due to the fact you need two pieces of information(url and revision number) to uniquely identify a piece of code whereas git just uses one: a SHA1 hash.
Do you have experiences with git-svn? Maybe by importing Boost's code?
Yes I do. I'm currently using git-svn with Gnome (I'm doing google summer of code with them). I thought I'd imported Boost's trunk at one time, but checking now it appears I've only got the sandbox+branches. I'll have a go at doing the main trunk but obviously it'll take some time. If I'm successful I'll quite happily make the repository available for people to try out using git-svn.