Branching Strategies [closed]

Answer 1

The first thing: KISS (Keep it simple stupid!)

/branches
  /RB-1.0 (*1)
  /RB-1.1 (*1)
  /RB-2.0 (*1)
/tags
  /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2)
  /REL-1.1
  /REL-2.0
/trunk
  current development with cool new features ;-)

*1) Keep version maintainable - e.g. Service Packs, Hotfixes, Bugfixes which may be merged to trunk if necessary and/or needed) *2) major.minor.build.revision

Rules of the thumb:

1. The Tags folder need not to be checked out
2. Only few coding in release branches (makes merging simpler) - no code cleanup etc.
3. Never to coding in tags folder
4. Never put concrete version information into source files. Use Place-holders or 0.0.0.0 which the build mechanism will replace by the version number you're building
5. Never put third party libraries into your source control (also no one will add STL, MFC etc. libraries to SVN ;-))
6. Only commit code that compiles
7. Prefer using environment variables instead of hard-coded paths (absolute and relative paths)

--hfrmobile