The Microsoft Corporation answer to Version Control (but no more, i.e. esp. not to Software Configuration Management - Visual Studio Team System). See the home page at www.microsoft.com 
.
Source Safe was originally written at One Tree Corporation by Brian Harry and Kenny Felder and was purchased by Microsoft in 1994. Later, Brian Harry went on to lead the team developing the virtual machine technology behind .Net.
Microsoft's own internally-written version control was a development of RCS called "SLM"; it was given a truly horrid GUI and released as Microsoft Delta... oh GOD it was bad it was so so SOOOOOO bad.... which is why they bought Source Safe, they were THAT humiliated by the reviews of Delta. Most projects at MS now use a version of Perforce Version Control they call "Source Depot".
Source Safe melds itself with other Microsoft applications like Visual Studio and Visual InterDev. Microsoft only supports Source Safe for Windows platforms. The following Microsoft partners offer non-Windows version of Source Safe:
Dynamsoft (www.dynamsoft.com ) offers a Source Safe add-on product Source Anywhere for VSS (www.dynamsoft.com ) that provides a pure Java Client for Source Safe. This Java Client can run on any platform where JVM can run, including Linux, Unix, Macintosh, Solaris, etc.
SLM is pronounced /Slime/, and people at Microsoft still use that product. Some even call /Slame/.
It works pretty much like CVS, only that it doesn't have branches nor tags, and also when two people check-in the same file, well the second developer is stopped by CVS saying he needs to update again, then check-in. SLM just overwrites the first check-in, adios change set. That's really lame.
See:
Micro Soft's Change Control software. It's actually pretty good, although this is coming from someone who's never used anything else really. There is a definite problem with usage by multiple users on a network. -- Anonymous Donor
Not to be snarky, but the statement "pretty good" and "problem with multiple users on the network" cannot co-exist when discussing a version-control product.
I've used a number of source control tools, and I'd say that Source Safe's strengths are that it's cheap, easy to use and well integrated with Micro Soft's Visual Studio tools. But it has a number of weaknesses too. I'd recommend a heavy investment in time and money in better tools, if you really want to get serious about versioning your source configuration.
-- Jeff Grigg (currently using SS)
It is not "well integrated". Do you mean that it has a pretty interface? Source control information on a client is 'usually' (no integration) stored in a file in the controlled directory. The Visual Studio integration works by duplicating the source control location for projects into two new places, the solution file and the project files. I don't know why it is written that way, but the duplication causes trouble if you need to do something obscure like branching a project and you don't know exactly how the integration works. It has caused me all sorts of trouble. Maybe you assumed that they did a good job of it since GUIs are supposedly their strong point, but that isn't the case. --Jesse Millikan
Perforce Version Control is cheap too, and better in all ways. Actually, it is even free for a two-user license (can be downloaded on www.perforce.com ), allowing me to use it for personal needs at home. Perforce uses Tcp Ip instead of Net Bios and thus works much better over the Internet. Plus it's available for a large number of other platforms.
Code Co-op is a lesser known tool, however I must say it has simplified our lives. Code Co-op lets us work together on our LAN and through Email when we're traveling. I don't know of any other system that can do this, and so seamlessly. I'm always in synch with my group no matter where I am. (is this good? ha) BTW, Code Co-op is really affordable. Last I checked, it's only $159 per user.
-- Mick
If this is Microsoft's answer to source control, I'd *hate* to think what the question was....
So far as I can tell, Source Safe is a really pretty GUI wrapped so tight around an RCS clone that you can hardly see the original. (Some of the tags are the same.)
It's portable ... as long as your idea of "portable" means "Windows 95 and Windows NT". There's a Unix implementation by Mainsoft, which I've charitably heard described as "a disaster". (Its locking scheme is incompatible with the Windows version, for example.) At my last job, Unix programmers needed Windows systems to put Unix source files under control with Windows Source Safe. (It was too Windows-centric a place to provide a separate repository for Unix software, and too Microsoft-centric to move to a truly cross-platform system.) -- Paul Chisholm
I've never used VSS in a cross-platform environment, but it's OK for a small shop that's only using Windows platforms. Tight integration with the tools is a big plus. -- Katy Mulvey
The above pretty much reflects my opinions of Source Safe 4.0, but 5.0, which I'm just trying out now, promises a project-oriented merging-model CVS kind of thing. No idea to what extent it delivers - shall report my experience here. -- Peter Merel
We're using Source Safe 5.0 for about a year now, and it is still an RCS clone with multiple check-out ability (which is still a great improvement on 4.0). It don't even come close to CVS. For example, it is unable to do (or at least I wasn't able to find out how to do) file-level branching, and historic tagging (rtag), just to name a few things I miss. By the way, does anyone know of a CVS integration with Dev Studio? (I'm a CLI kind of guy, but the team I work with will never switch over unless it works and looks like Source Safe.) -- Kristof Kovacs
Re: tagging, are you looking for "Labels"? Re: branching, are you looking for "Branch file?" (you have to share the file across separate projects first, of course) Re: CLI, have you seen SS.EXE? Did you look in the help? The toolbar? Is this a case of Anti Microsoft Bias On Wiki?
I don't think so. Branching in Source Safe is needlessly complicated. In most systems, you just tag the files, and it sorts itself out. In Source Safe, you have to branch the project (which shares the files between the new project and the old project), and then break the link. Merging the branches back together is a pain. The main disadvantage (in my opinion) of working this way is that your repository ends up cluttered with versions of the project that you no longer need. And just for the record, I'm not an example of the Anti Microsoft Bias On Wiki - I'm currently using IE5, NT4 and VC6 (with CVS ;-) -- Roger Lipscombe
People complain Source Safe isn't CVS because it doesn't have an archaic CLI - except that it does. Or that it doesn't have file branching - except that it does. Perhaps these people consider all source control to be CVS and any deviants (especially from Microsoft) are just wrong for no good reason.
Or perhaps they don't. Bah!
Broaden your perspective. There are other ways to live than your way. You may just learn something new and cool and worthwhile.
Let's have a look at the original comment and see whether it is justified:
We're using Source Safe 5.0 for about a year now, and it is still an RCS clone with multiple check-out ability (which is still a great improvement on 4.0). It don't even come close to CVS. For example, it is unable to do (or at least I wasn't able to find out how to do) file-level branching, and historic tagging (rtag), just to name a few things I miss. By the way, does anyone know of a CVS integration with Dev Studio? (I'm a CLI kind of guy, but the team I work with will never switch over unless it works and looks like Source Safe.) -- Kristof Kovacs
People who complain that Source Safe isn't CVS because it doesn't have an archaic CLI: Well, no, Kristof didn't do that. He said that he likes CLIs but his co-workers don't, which is why they won't use CVS unless it's made Source Safe-like.
... Or that it doesn't have file branching -- except that it does: Yes, it does. Kristof got that wrong. (It's pretty cumbersome, though.)
Sam also took exception to Kristof's statement that Source Safe doesn't do tagging. Well, it doesn't. It has "labels" on files, but you can only ever have one label on any version of a file or project. That means you can't do a lot of the things you can with, say, CVS tags or Perforce labels. Does that indicate that Sam is prejudiced and is unable to see that there could be anything similar to Source Safe's labels but enough better to make people complain about its absence? Let's assume not. So if making a mistake when comparing products is OK, what exactly justifies Sam's accusations against Kristof?
I think the Wiki would be a better place if everyone here could learn to disagree without flinging around accusations of dishonesty, prejudice, blinkeredness, and stupidity. How about it? -- Gareth Mc Caughan
For the record, does Source Safe have clients for other environments, say Unix or Macintosh? That would be my biggest gripe with Source Safe if the answer were no. -- Jacob Cohen
Source Safe is available for both Unix and Mac Os, though not from Micro Soft. The Unix version comes from Main Soft, and the Mac version comes from Metro Werks. -- Mike Smith
Me too. I would like to see how difficult the Dev Studio CVS integration would be. I just joined a team that has moved from PVCS to Source Safe. I have no personal experience, but I heard once that the integration with VB is so buggy that developers are forced to use the stand alone VSS client. (I will confirm this rumor tomorrow when I actually get a workstation from IS.) -- Terrel Shumway
[I think that it's not impossible. Perforce does it. -- Ken Wronkiewicz]
Would you care to share your experiences with Perforce Version Control? -- Bodo Maass
It's doable. See www.jalindi.com for a good implementation. I used it briefly to take advantage of Slick Edit's support for the API - made switching from Source Safe on the previous job to CVS on the current much easier. Then I got used to Win Cvs, which is nice it its own way. -- Laurent Bossavit
Ask yourself why you want the integration. Is it because developers are doing check-out-edit-check-in all day long? In our case we found it easier to ditch the integration thanks to CVS' non-exclusive checkouts. Developers checkout all files read-write and do a checkin/update with WinCVS when they come to a natural stopping point. The dev environment behaves as a simple single-user application (== happy developers). The bottom line: while IDE integration is essential for Source Safe, you may find it unnecessary with CVS. I know this does not fit with every company's culture. Jalindi, mentioned above, works fine if you still prefer IDE integration. -- Nate Silva
The programmer codes it up, tests it to death (or vice versa), and checks it in. Warning: Use a real versioning system like Source Safe and unlike CVS, or else the multiple checkins will kill you. -- Sunir Shah
It just occurred to me: I don't think I have ever seen a useful statement of the the form "Use a real foo such as bar, instead of that useless baz". I expect it is possible to build such a statement, but out of the hundreds/thousands of instances I have seen, I can't recall a single useful one. Most are either merely flamebait, or oversimplify an issue.
What is it that makes Source Safe real and CVS not? One of the anecdotal "old wives tales" about Source Safe is that it's really bad at merging difference check-ins of the same file. The behavior of CVS merge is said to be much better. Therefore the usual practice in Source Safe shops is to turn on exclusive check-outs, which prevents one programmer from checking out for write a file when another has it checked out. On the other hand, CVS shops tend to not worry about that and let the merge tool clean things up.
Source Safe provides consistent model of the managed content. It is simple and correct by default (because exclusive check-outs are transactional). Unlike CVS Source Safe doesn't force you to think how the system will accomplish what you need.
The issue of checkout/merge is mixed up with control and shop culture. Source Safe appears to be more common on those shops where central control and strict procedure-following is more valued, whereas CVS appears more in shops where there is a distribution of power and more communication between programmers to solve problems. In my experience, in shops where there is a good team, two programmers rarely work on the same file, and when they do it is on non-overlapping sections, so that CVS can merge them automatically. When there is a case where CVS flags the merge for manual intervention, it's usually solved by the two programmers working out the differences. However I do know of shops where there is a senior programmer or other self-appointed superstar who wants to work on all the code all the time and "fix" whatever the other programmers have done that wasn't to his standards, or who simply feels the need to work on things nominally assigned to other programmers because he feels he can do it faster/better. In this situation it's very common for the prima donna to get crossed up with other programmers when the others are trying to complete their own tasks. In this case, it's probably better to have exclusive lock until the prima donna can be weaned from trying to run everything.
There is a theory that exclusive lock enforces the good practice of the programmer doing a refresh of his or her local repository before doing a check-in. I suppose if the team needs a tool to enforce that then it's probably a good idea to have it, but most likely there are other issues that the version-control system can't fix. -- Steven Newton
People looking for an alternative to Source Safe should take a look at Clear Case or Perforce Version Control. Don't forget Sub Version too!
Unlike CVS Source Safe doesn't force you to think how the system will accomplish what you need Isn't that one of CVS's strengths? i.e., you need programmers who can think?
Source Safe's biggest weaknesses, in my experience:
Difficult to use from outside the local network. Requires a VPN tunnel, or a third party tool like Source Off Site. Even if all your developers are at one site, you'd still like to work from home or on the road.
VC integration breaks down as soon as you branch. VSS poops in your project and workspace files, as well as leaving those .scc files all over the damn place. After you branch it takes major surgery (or a well written script) to get all of those things pointing back to the correct branch. Every once in a while someone checks in a .dsp into our 4.1 branch that still points sourcesafe back to the 3.4 branch.
It's really honking slow. We have a project for each of our dlls, of which we have about 50, and 3 major branches for each project for 3.4, 4.0, and 4.1 version releases. Just getting all the most recent code for all projects on one branch into an empty directory takes 3-4 times what it would take just to copy them from some directory on the server. Just opening VC and having it connect to the 50 projects in my workspace takes way too long.
These reasons were more than enough for us to switch to CVS. And there are plenty more annoyances and quibbles besides. Plus more big issues when you try more complicated branch and merge maneuvers. -- Keith Wright
I'll add my $.02 about SourceSafe's weaknesses:
1. It is definitely slow - an order of magnitude slower than Perforce for instance. I have measured this personally. I don't know much about networking but I understand this has to do with the fact that Perforce uses TCP/IP while Source Safe uses the windows filesharing (but don't hold me to that).
2. On multiple occasions I have seen it crash its database somehow. When this happens you have to run this weird tool that rebuilds it very slowly, but doesn't always work. Has anyone else seen the "wucbaaaaaaaa" (if I remember correctly) error?
''Yes, I've seen similar database corruption in VSS. We dropped it like a white hot potato after the first time it corrupted our files and history! Any tool with a "repair repository" menuitem should be avoided.''
3. The atomic checkins of Perforce are much cleaner than Source Safe's weak database model. One aspect of this is that Source Safe won't delete files for you, leading me in the past to have to do lame things like send emails to my coworkers telling them to delete such and such a file.
I spent about 3 years working on Sun's NSE, and about 1 year on Sun's Teamware, so I have very strong bias W/R/T source control. I'm using VSS now, and have used Perforce, CVS, and MKS previously.
To confirm what others have stated, VSS is very slow, especially compared with Perforce, and it makes branching and merging much more difficult than it should be. The GUI's are merely adequate, a surprise for an MS product, and the command line is less so, particularly w/r/t documentation. More fundamentally, it shares the same flaw as NSE, Clear Case, and Perforce; it has a central repository, which is so 1990's. Aside from introducing a single point of failure, central repository systems don't scale well, and they don't model development in the Internet era which tends to be distributed.
(Clear Case Multisite has a distributed database architecture. It seems to scale rather well in my experience. --Mark Schumann)
Unfortunately, Sun's Teamware died due to Sun's ineptitude in marketing software (except Java, which was an accident), but Bit Keeper borrows most of the concepts, is multiplatform, and is supported by Bit Mover.
It is sometimes necessary to look at the history of a file and compare two old versions to each other. When I have a file checked out and I'm working on a particular part of the code, I might notice some other unrelated part that needs cleaning up, refactoring, or which could be made more efficient. But then I remember that later if I look back at the history, then the real purpose of my change will be lost because when I "Diff" two versions, the modifications I made to the unrelated areas will be highlighted along with my "real" change. This discourages good code maintenance. Anybody else have this experience? Or am I being too lazy by refusing the check-out, check-in, check-out, check-in to record the two different modifications separately? -- Joseph Styons
(Note that this issue isn't specific to Source Safe.) I just make the unrelated changes in the same changeset, and note them separately in the checkin comments. This only becomes a problem if one change needs to be backed out, and not the other, and that occurrence is too rare to worry about much. -- Dan Muller
That has actually worked to my advantage on more than one occasion. If you have a boss or uncooperative team member who is biased against refactoring on the grounds of "introducing variables" or "why change it if it works", then combined commits are your friends. The only way to justify refactoring with these people is by saying that it was a necessary part of fixing a bug, or that is was the most natural course for fixing a bug. Then if they want to entertain the idea of removing the "extra" changes, just explain that you don't understand how it would be done another way. If they offer to explain another way, suggest that since they already know how it should be done, it would be quicker if they do it themself. -- Michael Sparks
My favorite "quirk" is what happens if you have the misfortune to run out of disk space when VSS wants to do a check in. Not only will it fail, you'll corrupt the file and lose the history. If you're lucky, you'll be able to recover the last version.
You can see some more documented features here: support.microsoft.com . I especially like what it says about the tools for recovery from data corruption, "Data corruption occurs if you use the FIX* tools with a Visual Source Safe 4.x or 5.x database."
I've just joined a team that uses VSS. I've come from a team where I used SVN and built an automated build and test system that was triggered off commits. I'd like to do the same with VSS so I checked MSDN to see how to do it...
Oh my god!!! I was doing this with a 20 line ruby script that included code to send notification emails!
-- hjm
See original on c2.com