That is to say, main development will take place in the trunk (/trunk/). Main development here means reasonably stable, yet untested, development. This means that the trunk should always compile, and run reasonably predictable. Ofcourse mistakes are made so both of those two conditions can be violated at some times but should be corrected rather fast. (Apart from mistakes, these two conditions are usually met.)DevUrandom wrote: Code which is or is going to be released, resides in /branches/. Eg. 2.0.6 is in /branches/2.0/. This is for bugfixes and tiny features.
Code which is in active development is in /trunk/.
Then as for branches we should really distinguish between two distinct kinds of branches:
- release branches;
- development branches
Development branches are branches for certain lines of development which will most likely cause a severe destabilization of the regular codebase. So to prevent severe destabilization of the trunk they're moved into an isolated area (the respective dev branch), so they don't cause problems for people working on the trunk. (E.g. the sound branch is a development branch by this definition, /branches/sound/)
That is to say, revision numbers in combination with the respective branch (or trunk) can be used as a means of identification, but are nothing more than that: a means of identification.DevUrandom wrote: The revision is a versioning number SVN provides for the whole source. It is not specific for stable or development version. From a simple revision number you can not immediately see whether it was a change to the /trunk/ or to /branches/2.0/. This number is not updated by us, but by SVN when we "upload" code into the repository. It can _not_ be seen as a release. It merely is something for developers so they know about which change to the sourcecode someone is talking.
That might help to understand how Subversion works. It still lacks the why though, that's a design philosophy, which although it doesn't receive as much attention in the SVN-book is just as important (maybe even more). That however is the result from the fact that large parts of this philosophy are not specific to Subversion only, but to version control in general.DevUrandom wrote: Maybe you want to have a look into the SVN manual for the basics...
PS: the parts of the Subversion manual on branching & tagging focus mainly on how to branch/tag as opposed to how it would have to be done using CVS (Subversion's predecessor).
