<p>I know there are at least 10 different ways to structure project in version control. I'm curious what some methods being used are and which ones work for you.  I've worked with SVN, TFS, and currently/unfortunately VSS.  I've seen version control implemented very poorly and just OK, but never great.</p>

<p>Just to get the ball rolling, here is a review of things I've seen.</p>

<p>This example is SVN-based, but applies to most VCS's (not so much to distributed version control).</p>

<ol>
<li><p>branch the individual projects that are part of site
/division/web/projectName/vb/src/[trunk|branches|tags]</p></li>
<li><p>branch the whole site, in the case I've seen, the whole site except for core components was branched.
/division/[trunk|branches|tags]/web/projectName/vb/src/</p></li>
<li><p>Use main-line a default, only branch when necessary for <strong>huge</strong> changes.</p></li>
</ol>

Example for SVN:
trunk/
branch/
tags/
The trunk should be kept at a point where you can always push a release from it. There should be no huge gaping bugs that you know about(of course there will be eventually but that is what you should strive for).
Every time you need to make a new feature, do a design change, whatever, branch. Tag that branch at the start. Then when you are finished with the branch tag it at the end. This helps out with merging back into trunk.
Every time you need to push a release, tag. This way if something goes horribly wrong you can rollback to the previous release.
This setup keeps trunk as clean as possible and allows you to make quick bug fixes and push them out while keeping the majority of your development in branches.
Edit:
For 3rd party stuff it depends. If I can avoid it I do not have it under source control. I keep it in a directory outside source control and include it from there. For things like jquery, I do leave it under source control. The reason is it simplifies my script for pushing. I can simply have it do an svn export and rsync.