This is one of the most common common questions I see and I’ve always intended to create a polished, scenario-driven, reusable answer for my FAQ library. Here’s a first stab. If you’ve seen better, please provide links. Ideas for how I can improve this? Please leave your comments. For a great list of VSS-specific FAQs, see Mark Michalis’ amazing http://www.michaelis.net/SourceSafe/Faq.htm.
Q: Just wondering what any of you think about VSS – Should I use this product or not? If so, how will it help me as a newbie? Thanks for any feedback!
A: SourceSafe is primarily designed for and used by software development professionals. In collaborative development environments, it can be used to enforce code access control: allowing only one person at a time to check out source files in order to limit editorial conflicts. On the flip side, many teams use VSS to facilitate ‘parallel development’, where two or more developers work on the same source file(s) at the same time. In the latter case, when each developer checks in their local changes to the SourceSafe database, SourceSafe automatically merges their changes, if possible. If two or more developers change the same line of code, SourceSafe prompts them and gives them tools to manually choose which change they want to keep.
Even if you work alone, VSS can help immensely. Let’s say you write the canonical ASP.NET datagrid app called ‘Library’ that displays a picture (from Amazon, of course) and other information about the burgeoning number of technical books in your personal programmer’s library. Like any good experimental programmer (ahem, newbie), your primary purpose in writing this app is to explore different coding techniques, technologies, and developmental processes. You code for what seems like 100 hours and in the end your library app is a perfect thing of beauty. Thinking that you might even be able to market it online as shareware, you email your code to a friend [BRANCH]* for code review and informal beta testing. Fifteen minutes later he responds,
“Dude, cool app but SQL Server is *way* overkill. Unless you set this up as a hosted Web service or something, your end users won’t be able to afford it. Convert the back end to XML.”
You consider this directive for a long, long moment [SQL Server hums contentedly in the background] and you think, ‘Well heck, I have been meaning to dive into XPath and the XML DOM. Let’s do it.’
Two days later your Library app is in shambles, you wish you’d never seen the word ‘Exception’, and ctrl+z can’t turn back the clock. You freak out, bare your teeth, scream like a banshee, hurl small objects at the wall, and inadvertently spill your diet Coke on your petrified cat. You just experienced an uncontrolled moment. [‘Got Source Control?’] If you had been using SourceSafe, checking out your project files for edit and checking in your changes every so often, you would have been able to rollback to a specific version in time or better, to a specific labeled version.
*[BRANCH] – Branch is a source control term that indicates a break in the continuous development of a codeline. The most common reason that developers branch a codeline in a source control database is to create a patch for a specific version (eg, bug fixes for a released Beta 1) that they can test in isolation, deploy to end users, and later integrate into the main, evolving branch (eg unreleased Beta2).
If you email code to a friend, you don’t literally branch your application’s codeline as you would in VSS; you do so informally. Now imagine that you continue to work on your version of Library while simultaneously and unbeknownst to you, your friend starts to work on it as well. After two weeks, he proudly emails you his version of the Library Web app. It rocks. You decide to blend some of his enhancements into your version of the application but discover that it’s nearly impossible to do so without completely overwriting your most recent changes. You just experienced an uncontrolled moment. SourceSafe could have helped.
For more blog posts about source control in general, click Source Control. For more blog posts about VSS in particular, see Visual SourceSafe or VSS Tips and Tricks. You can also visit the SourceSafe home page. If you’re really desperate, you can visit the microsoft.public.vsnet.vss newsgroup 24×7 to ask some of the world’s foremost experts on source control questions about VSS and source control integration for Visual Studio .NET.