I asked myself the same questions when we came to implement Subversion here — about 20 developers spread across 4 – 6 projects. I didn’t find any one good source with ”the answer”. Here are some parts of how our answer has developed over the last 3 years:
— commit as often as is useful; our rule of thumb is commit whenever you have done sufficient work that it would be a problem having to re-do it if the modifications got lost; sometimes I commit every 15 minutes or so, other times it might be days (yes, sometimes it takes me a day to write 1 line of code)
— we use branches, as one of your earlier answers suggested, for different development paths; right now for one of our programs we have 3 active branches: 1 for the main development, 1 for the as-yet-unfinished effort to parallelise the program, and 1 for the effort to revise it to use XML input and output files;
— we scarcely use tags, though we think we ought to use them to identify releases to production;
Think of development proceeding along a single path. At some time or state of development marketing decide to release the first version of the product, so you plant a flag in the path labelled ‘1’ (or ‘1.0’ or what have you). At some other time some bright spark decides to parallelise the program, but decides that that will take weeks and that people want to keep going down the main path in the meantime. So you build a fork in the path and different people wander off down the different forks.
The flags in the road are called ‘tags’ ,and the forks in the road are where ‘branches’ divide. Occasionally, also, branches come back together.
— we put all material necessary to build an executable (or system) into the repository; That means at least source code and make file (or project files for Visual Studio). But when we have icons and config files and all that other stuff, that goes into the repository. Some documentation finds its way into the repo; certainly any documentation such as help files which might be integral to the program does, and it’s a useful place to put developer documentation.
We even put Windows executables for our production releases in there, to provide a single location for people looking for software — our Linux releases go to a server so don’t need to be stored.
— we don’t require that the repository at all times be capable of delivering a latest version which builds and executes; some projects work that way, some don’t; the decision rests with the project manager and depends on many factors but I think it breaks down when making major changes to a program.