Source Safe
Source SafeThe MicrosoftCorporation answer to VersionControl (but no more, i.e. esp. not to SoftwareConfigurationManagement - VisualStudioTeamSystem). See the home page at http://www.microsoft.com/ssafe/.
SourceSafe was originally written at OneTree? 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 MicrosoftDelta... oh GOD it was bad it was so so SOOOOOO bad.... which is why they bought SourceSafe, they were THAT humiliated by the reviews of Delta. Most projects at MS now use a version of PerforceVersionControl they call "Source Depot".
SourceSafe melds itself with other Microsoft applications like VisualStudio and Visual InterDev. Microsoft only supports SourceSafe for Windows platforms. The following Microsoft partners offer non-Windows version of SourceSafe:
Dynamsoft (http://www.dynamsoft.com/) offers a SourceSafe add-on product SourceAnywhere for VSS (http://www.dynamsoft.com/Products/SAW_Overview.aspx) that provides a pure Java Client for SourceSafe. 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:
MicroSoft's ChangeControl? 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. -- AnonymousDonor
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 SourceSafe's strengths are that it's cheap, easy to use and well integrated with MicroSoft's VisualStudio 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. -- JeffGrigg (currently using SS)
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, SourceSafe 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 SourceSafe. (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.) -- PaulChisholm
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. -- KatyMulvey
The above pretty much reflects my opinions of SourceSafe 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. -- PeterMerel
We're using SourceSafe 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 DevStudio?? (I'm a CLI kind of guy, but the team I work with will never switch over unless it works and looks like SourceSafe.) -- KristofKovacs?
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 AntiMicrosoftBiasOnWiki?
I don't think so. Branching in SourceSafe is needlessly complicated. In most systems, you just tag the files, and it sorts itself out. In SourceSafe, 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 AntiMicrosoftBiasOnWiki - I'm currently using IE5, NT4 and VC6 (with CVS ;-) -- RogerLipscombe
People complain SourceSafe 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:
... 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 SourceSafe 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 SourceSafe'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? -- GarethMcCaughan
For the record, does SourceSafe have clients for other environments, say Unix or Macintosh? That would be my biggest gripe with SourceSafe if the answer were no. -- JacobCohen
SourceSafe is available for both Unix and MacOs, though not from MicroSoft. The Unix version comes from MainSoft?, and the Mac version comes from MetroWerks. -- MikeSmith
Me too. I would like to see how difficult the DevStudio? CVS integration would be. I just joined a team that has moved from PVCS to SourceSafe. 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.) -- TerrelShumway
[I think that it's not impossible. Perforce does it. -- KenWronkiewicz]
Would you care to share your experiences with PerforceVersionControl? -- BodoMaass
It's doable. See http://www.jalindi.com/igloo/ for a good implementation. I used it briefly to take advantage of SlickEdit's support for the API - made switching from SourceSafe on the previous job to CVS on the current much easier. Then I got used to WinCvs, which is nice it its own way. -- LaurentBossavit
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 SourceSafe, 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. -- NateSilva?
The programmer codes it up, tests it to death (or vice versa), and checks it in. Warning: Use a real versioning system like SourceSafe and unlike CVS, or else the multiple checkins will kill you. -- SunirShah
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 SourceSafe real and CVS not? One of the anecdotal "old wives tales" about SourceSafe 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 SourceSafe 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.
SourceSafe provides consistent model of the managed content. It is simple and correct by default (because exclusive check-outs are transactional). Unlike CVS SourceSafe 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. SourceSafe 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. -- StevenNewton
See also BondageAndDisciplineVersionControl
People looking for an alternative to SourceSafe should take a look at ClearCase or PerforceVersionControl. Don't forget SubVersion too!
Unlike CVS SourceSafe 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:
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 SourceSafe 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 SourceSafe's weak database model. One aspect of this is that SourceSafe 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, ClearCase, 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.
(ClearCase Multisite has a distributed database architecture. It seems to scale rather well in my experience. --MarkSchumann)
Unfortunately, Sun's Teamware died due to Sun's ineptitude in marketing software (except Java, which was an accident), but BitKeeper borrows most of the concepts, is multiplatform, and is supported by BitMover?.
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? -- JosephStyons
(Note that this issue isn't specific to SourceSafe.) 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. -- DanMuller
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. -- MichaelSparks
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: http://support.microsoft.com/kb/q133054/. 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 SourceSafe 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...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvss/html/vssauto.asp
Oh my god!!! I was doing this with a 20 line ruby script that included code to send notification emails!
-- hjm
EditText of this page
(last edited December 24, 2007)
or FindPage with title or text search