Why not use sourcesafe

Users only needing read-only access to the revision control system need write access to the server, increasing the risk Required Network Rights for the SourceSafe Directories. Viruses can completely destroy not only your client computer but also your server repository.

SourceSafe should be scanned for corruption weekly Of course, with this high risk of corruption, Microsoft recommends that you run the Analyze diagnostic program weekly.

While Analyze is running all of your developers are locked out of the system everyone must remember to quit from SourceSafe first! My experience shows that repositories with a few gigabytes takes several hours usually the whole night to check. SourceSafe handles multiple time zones badly Since each client is responsible for everything, there is no such thing as a "server time".

Each client tracks it's own time, and even with users on the same timezone, you can easily lose files if all computer clocks are not synchronized. SourceSafe becomes corrupted Your revision control system must be trustworthy. You're entrusting your hard work to your revision control system. If your data is corrupted, the system is worthless. SourceSafe's fundamental design assumes that clients are trustworthy, always function correctly, and that nothing interferes with the communication causing corrupted data.

As a result, SourceSafe is fragile and untrustworthy. I have worked with SourceSafe at many different jobs, and in all of them eventually the SourceSafe database became corrupted.

Data has been corrupted, work has been lost, time has been wasted on the problem. If you speak with other developers, you'll hear similar experiences.

Comparing your local version to the remote repository is clumsy. You select the directory you're interested in SourceSafe and select Compare Differences. The resulting report is modal, preventing you from working with SourceSafe while examining the report. When getting the latest version of files from SourceSafe, each file changed locally causes a dialog to pop up to confirm the update.

The update action entirely stops while the dialog waits for your response. You can prevent the dialog from returning in several ways, but in doing so you get no indication that any such files were encountered.

So when you return to the finished update, you will have no idea that SourceSafe encountered potential problems. SourceSafe should note these files in the output window when encountered, making it easy to scan the output window for files to be investigated.

Make the switch to team system , subversion , or any other modern source control system of your choice, but whatever you do, please don't use visual sourcesafe.

Reference 1 Reference 2. Microsoft SourceSafe has been discontinued, and has a long list of problems and limitations. Since I was new to the company then it might have been dangerous to me. There's better ones that are easier to use, safer to use, and are completely free. Why bother using it at all? Using SourceSafe in a commercial operation is like heating the building by burning dollar bills. It was only that low because we'd gone to hourly backups. VSS effectively puts you on dope, to the extent that you can't reconcile any sort of reality needed to realize that your now borked repo wasn't your fault.

Had it bite me quite a few times, but inertia is difficult to overcome. It was faster to manually find the files that changed, zip them up, email them, remote in to the source vault machine, unzip them, and check in the code from the source vault machine.

Switched to Mercurial. I can clone the entire source code base across the VPN in under a minute. And I no longer fear branching. I used it for a long time nearly 10 years without ever personally experiencing any issues including within the teams I was working in though our code tended to be fairly well divided up to avoid conflicts and the like.

But there are far too many stories of data loss to keep using it when there are decent, reliable open source alternatives out there. Edit: From the comments the message seems to be avoid anything complex branching, merging, conflicts and you're probably fine.

Anything more and you're heading into risky territory. For a solo or really small shop working in Visual Studio 6 or something older it is passable and better than nothing. I think there is a lot of exaggeration about how bad it was, but then it only takes one instance of losing valuable work to sour you on a product for good reason.

VSS had its place, and I credit it for at least encouraging a lot of developers who were using no SCM tool at all to get into the habit, but like many technologies it is now pretty much obsolete. The most annoying part about it is not it's awful versioning and confusing branching ability, but the list box on the file menu doesn't let you hit the right arrow key to expand.

My view on VSS? I declined a few job offers very well paid because they requested "VSS proficiency". And I am sure there is a couple of other people here who did the same. Not only do you suffer from the problem of potential corruption of source which should be argument enough for management to replace it , but you also have to live with awkward backup and an inability to work effectively as a team on different streams of work.

Find another SCM any other one and look at how easy branching and merging can be. Think about those times when you've had to copy files out of your VSS solution and hold them somewhere else while you went back to fix a bug on 'production' code. SCM tools should be more than just source backup. My views on VSS? Used it for a long time regularly still used ocasionally for older components but it's too XX century for our team:.

The new Team Foundation stuff was supposed to help a lot, and try to get away from the bad parts of VSS. Sorry for any confusion. VSS, in Visual Studio 6, for all it's failures and problems had distinct advantages.

I cannot figure out why everybody wants to badmouth VSS. VSS is not distributed, and distributed version control is. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Learn more. Is SourceSafe really safe? Ask Question. Asked 10 years, 11 months ago. Active 9 years ago. Viewed 2k times. Improve this question. Oh dear God NO I fought long and hard to get SourceSafe out of my company.

Eventually won and everyone is happier for it. The phrase "Checking in early and often. You should never lose more than a few hours of work. Run for your life! Microsoft doesn't use it. Why should we? Show 5 more comments. Active Oldest Votes. Relatedly, this is a potential problem if any of the client computers using SourceSafe fail to have synchronized clocks. Differences of several minutes between computers can cause strange behavior from SourceSafe with it tries to reconcile information that appears to come from the future.

Your revision control system must be trustworthy. You're entrusting your hard work to your revision control system. If your data is corrupted, the system is worthless. SourceSafe's fundamental design assumes that clients are trustworthy, always function correctly, and that nothing interferes with the communication causing corrupted data. As a result, SourceSafe is fragile and untrustworthy. I have worked with SourceSafe at three different jobs. In each case, eventually the SourceSafe database became corrupted.

Data has been corrupted, work has been lost, time has been wasted on the problem. Speaking with other developers, I have learned that my experiences are not unique.

Minor actions like changing the directory erase the entire contents of the output window, making it difficult to examine past actions. Comparing your local version to the remote repository is clumsy. You select the directory you're interested in SourceSafe and select Compare Differences. The resulting report is modal, preventing you from working with SourceSafe while examining the report.

When getting the latest version of files from SourceSafe, each file changed locally causes a dialog to pop up to confirm the update. The update action entirely stops while the dialog waits for your response. You can prevent the dialog from returning in several ways, but in doing so you get no indication that any such files were encountered.

So when you return to the finished update, you will have no idea that SourceSafe encountered potential problems. SourceSafe should note these files in the output window when encountered, making it easy to scan the output window for files to be investigated.

If you're considering SourceSafe, consider something else. If you're using SourceSafe now, migrate away as soon as possible. Here are just a few. If you simply must use SourceSafe, definitely take the time to look at Microsoft's list of bugs in Visual SourceSafe 6.

These links were originally taken from Microsoft's Bugs page. This page may be useful if you have a different version of SourceSafe or the above links fail. We gave VSS it's own dedicated server - real physical hardware - in order to minimize disruptions, and still we had regular problems. Once a week I had to go and fix broken locks - locks that couldn't be released by the developer who placed them.

Around twice a year I had to recover from a corrupted repository - there seemed to be some kind of built-in limit at around the 1G mark, whenever the repository grew much past 1G things went bad pretty quickly.

Given that there are better tools - with better integrations - that are now available at zero-cost, switching from VSS to me is a no-brainer. I agree that VSS is a horrible piece of software but other than the possible database corruption problem, it seems like your situation will be a difficult one to sell people on. For example, you can't say VSS has terrible merge support because, well, you're the only developer. You can't complain about locking checkouts for the same reason.

Unless your app is pretty good sized, you can't argue from the suggested 1 GB maximum database size that VSS suggests.

I personally think that in an interview like you're suggesting, you'd be better off looking for lower hanging fruit to suggest like iterative development, TDD or a wiki for documentation. I have fought the good fight to move from VSS to Perforce in an enterprise situation and that was hard enough. I can't imagine trying to convince management of a major source control change on an application that has one developer.

SourceSafe is an antiquated technology built upon Windows shares. The storage mechanism non-transactional "flat files" is a recipe for poor performance and bugs. Its adoption has nothing to do with what it has over other SCM's, and everything to do with the fact that it was "already there".

I can't comment on Perforce, but I can say that VSS compared to, say, Team Foundation Server is a very weak offering and should be used only in circumstances where there is already a large investment in it and NO money can be spent.

Microsoft does not use it internally. Instead, they got a source license to Perforce, and they've hacked it up to suit their needs. This is telling, since Microsoft proudly dogfoods their other products, like Windows and Office.

My last experience with Sourcesafe was years ago, so take this with a grain of salt. In my experience, it doesn't scale well as the number of developers touching the same code goes up. There is no way to have multiple people working on the same code, and then merging their changes together on check-in.

Instead, each developer has to lock the files they are working on, while the other developers can't make progress on anything touching those same files. The issue I'm wreslting with now is Visual Source Safe's insistence that my project's folder structure cannot possibly be represented within the target working directory. It always thinks that a service setup project is trying to encroach on the service project and refuses to check it in. When you add a project to source control, it invariably adds another folder to its path in source control.

One of the issues that I have read there, and I haven't seen mentioned so far in the answers, is that VSS has no support for deleted then recreated files : either you purge history of file and can never recover old version , or you can create file with the same name as some deleted file had.

Even CVS which is also file-based tried to did this right by using 'Attic' area. I can go on and on. The bottom line is to absolutely avoid this product. I think it may go well with smaller projects, but developing enterprise level applications should not involve dealing with constant codebase repository issues.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more.

Why is Visual SourceSafe viewed so poorly? Asked 12 years, 3 months ago. Active 3 years, 9 months ago. Viewed 4k times. Improve this question. Community Bot 1 1 1 silver badge.

Yes - that Jake. Add a comment. Active Oldest Votes. Improve this answer. John Saunders John Saunders k 24 24 gold badges silver badges bronze badges. But, why is it considered unreliable and "not up to modern standards? A reliable data store. It just stores files on a file share. No transactions. Microsoft Access is more reliable than that. This is probably the single best answer, but also the hardest to "prove" to someone unfamiliar with SS and sadly, even some who are.

Thing is, many teams just got "lucky" - SS worked just fine for them for years - and they took this as evidence that it wasn't all that bad. Like the program with serious concurrency issues that worked fine for a decade on single-processor machines Shog9: Unfortunately, these are also the people who aren't bothered by the fact that the most recent release of VSS is 6.

The same "6. John Saunders. My installed VSS is version 8. PNG — Matthew Lock. Show 1 more comment.