Steps to creating a new project and adding to source control
setting option for read-only on check-in (technically, when lock is released)
faqs, above
tips
annoyances
keywords (such as $log$ to show log of changes, or $date$ to show date of update in static file)
sharing, with VSS (or with versions, by creating new "share" project. clumsier.)
things to show: in versions, "files to check in" (how using it rather than studio to check in is fater: can list files to check in, files not in project--both not in studio) and can deal with several projects at once whereas multiples are combersome in Studio. maybe not even worth the bother to use studio projects), using "audit" tab then descendants & filters, file>report (CAN zoom in, and how you can export with briefcase icon or email with envelope), anchor on history means permanent, designating builds, (and don't forget project proerties' force check-in reason, use keywords)
things to show: in studio: using compare, and also compare to history (not on tools>source control, also must be sure to select version NUMBER, also show get from history--but for both, be careful. will sometimes get an error, which removes mark of file as readonly), how source control>undo checkout will wipe out changed file without prompt (check-out and get latest version would prompt you if file had changed), files to check in/check out (especially easy for finding files to check-in, and quicker to check in than studio--see above). comparing 2 versions in a file's history, using check out of all files as of a build or date. to fix as of a version, create subproject/branch, checkout a build to that dir, fix, and then merge changes in
