A branch is a "cheap copy" as you put it, of a file at a certain point in time, i.e. revision number.
If you continue working on the trunk, the branch will be unaffected, it will still point to its original revision. If you switch, and start working on a branch, this will also not affect the trunk. And you will still have available the entire history of the branch, from it's creation point on.
Tag is exactly the same, a "cheap copy", but all your developers must agree, that they will not touch a tag, because it is not protected.
If you want to protect it, you must create a hook script, that does that.
Your changes on the trunk will not be propagated to the branch. You can use svn merge to merge changes from the trunk into a branch.
Manuzhai, your statement implies that it is not possible to share a common, changing code base between multiple "versions" of a repository. I am also looking at converting from PVCS to SVN and this statement makes me question if I understand what process changes will result.
For instance, I have an archive that builds on 6 different platforms. Since each platform builds from a "project" file, I have 6 different versions of this file. Therefore, this single file has 6 different branches, with six different floating labels. All 6 tags are present on all of the rest of the files (which are the same for all platforms), so a build of any platform will retrieve all the necessary files and the one special project file.
All the other files change, but the floating label moves with them, so I always have the latest files when I build any one package. How _does_ one accomplish this feat in SVN without constantly merging the trunk back to a branch. It sounds like a lot of work, but I am hoping that there is just a "different" way of accomplishing the same goal.
Can't you construct your "project" in such a way, that it gets the platfrom specific files from some other location, and not from the trunk?
"You cannot do it" or "put those files into a separate directory" is what I expected to hear. In theory I am not opposed to this difference in philosophy, but it will make it difficult to migrate the current projects to subversion. This is a very common "pattern" for us.
Moving forward, if we choose subversion, I have to somehow wrap my head around this different way of thinking. It is difficult to see how it will play out for complex, multi-platform projects.
Thanks for the help everyone.
There is also a suggestion for using svn:external. Have you missed it?
I think branches could be the wrong approach to manage the different versions of a (OS-) specific problem. I could imagine those files should be placed in one common directory of the project. In svn it would be also just a common source file subdir. Not a branch.
Now, to build specific releases you do a checkout or export as usual. But instead of building all what is in your directory, just use the appropriate files and directories. So it becomes a question of the build managment (there are also tools available for this part of the software development (ant, make, ...)) and not anymore of the source control system. And that means that you do not need to use the branches in svn, which I think are intended for bug fix and experimental development (and maybe other things, but not for this problem).
Can anyone agree to this proposal? Would be interesting to read some comments.