<i>"10. Dependencies need a home too"</i><p>I agree with this statement, but that home is definitely not with your code. There are tools better suited for that. For instance nexus & maven.<p>Nexus store artifacts (which are really any piece of data: a jar, a tar.gz, a zip file). That's where you put your dependencies. Maven manage a project's build, that's where you tell what are your dependencies.<p>But really, there are many other tools out there to handle that (ant, nant, pypi, etc.).
<i>"In all fairness, VSS was a great tool."</i><p>I disagree. Even back in 1995 it had fatal flaws. More than once it got so confused that we had to restore the source tree from backup. There was also the continual problem of files being locked by others when they should not have been, hampering progress and complexities. I was glad when we could kick it out of the door.
I gave a skim and didn't find this<p>11. Never commit revisions which can't be built. (In the exceptional cases, always state in the commit message that the code doesn't build.)
This seems to assume that everyone is committing into the same branch. How about the workflow where you create a new branch for each work package and merge it into the main branch when finished? It lets you check in to your own branch as often as you want (even broken code) without worrying about breaking anything for the other devs. The merges will be bigger though, days or weeks of work. A good point is that the branch merge is a natural time to look through all the diffs.
<i>Compilation output does not belong in source control</i><p>I've seen this before, but never found a suitable alternative. Where does it belong? Suppose multiple developers are compiling a C++ .dll which testers are grabbing through websvn and testing. To track down crashes they get, we need the associated .pdb for the right revision. Where should these files be kept? In a plain folder where each revision gets its own subfolder named as the revision number? That means updating two separate locations with each build, using two different interfaces...
"6. You must commit your own changes - you can’t delegate it"<p>My company does this, and I'm not entirely sure how I feel about this. The motivation for delegating changes is that different groups in our company have different check-in priveleges. This results in half of my changes being committed by me and half the changes being committed by someone else. This does, of course, present some coordination problems though.
<i>subsequent commit messages from the same author should never be identical</i><p>I violate this one sometimes. I'm not a VCS magician, so sometimes I get commit errors, and wind up having to make a second commit. I figure identical commit messages makes it pretty obvious the two commits were intended to be one.