As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I am considering getting VSS and was wondering what were people's thoughts on it in particular?
It's well-known to corrupt data. There are many better alternatives. If you need to match the feature-set and GUI, check out Vault from SourceGear. Free alternatives are numerous --- from the ubiquitous svn to the more modern (distributed) git, mercurial, etc.
Also, TFS is the MS replacement -- if you want MS tools, at least use TFS.
Jeff Atwood has a nice post: Anything But SourceSafe
There is no excuse for using VSS when there are other solutions such as SVN, Git and Mercurial which are better both in terms of reliability and use more modern approach then VSS.
My thoughts:
AHHHHHHHHHRHRHRHGGGEHAGTJH##$#!&#&$!&###!##%^##$%
No. Seriously.
Before I knew how evil it was (newbie dev), I used it. Then, it corrupted an entire project I was working on. What a pile of garbage.
Use Subversion, Git, or Mercurial...for your own sanity.
Microsoft is pushing Team Foundation Server (TFS) as a replacement for VSS. VSS does offer the simplicity of a file based system, but you will spend a good amount of time repairing the database every so often. TFS is a much more reliable server based system. Visual Studio 2010 comes with a client license and a up to 5 person server license of TFS. You are better off putting your money there.
TFS Costs.
Because the question is a license/price issue, you can call 1-800-426-9400, Monday through Friday, 6:00 A.M. to 6:00 P.M. (Pacific Time) to speak directly to a Microsoft licensing specialist, and you can get more detail information from there.
Use TFS, Perforce, or maybe git.
Even if SourceSafe wasn't extremely dangerous to use (corruption, mentioned already)... just having file versions for source control really sucks. It's almost unbelievable that this type of source control is still widely used.
You want changeset or task-based source control. You'll want to easily know what files went into a specific change... not just a bunch of independently incrementing file numbers.
Perforce is VERY fast, and I'm very happy with it.
I use TFS for one major client, and it's been pretty good too. At the time I set up Perforce, TFS required a Server OS and license for that somewhere. I didn't want to have to set up yet another VM, so I went with Perforce.
I'd still easily choose Perforce today, though. That's mostly because I work with multiple platforms. As the main Perforce GUI client uses Qt, it looks and works the same on any OS.
VSS might be the right answer for some situations (e.g.: small group of devs using visual studio, not generally doing concurrent dev, fault tolerant env. (back-ups), etc.). I think the more important question is how your version control fits into your overall dev & release process. VSS and git are conceptually very different things in some very important ways and how your SDLC works is an important aspect of choosing a control system.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Given I'm:
a solo developer using VS2008 Professional
looking for Microsoft-produced source control (I'm aware there are alternatives)
looking to get away from Visual SourceSafe 2005
Is it correct that my only option is to drop ~$8k on Visual Studio Team System 2008 Development Edition ($5,469) + Team Foundation Server ($2,799) - in order to get the TFS version control component?
Reading the answers to other related questions it looks like routes to bringing the TFS price down is to either become a Microsoft Gold Certified partner or to take advantage of the ISV Empower program. I'd welcome any comments related to these options.
The top non-Microsoft solution looks to be Subversion + VisualSVN, but I'd really like to go the all-Microsoft route if I can possibly swing it.
The reason that I'd like to go all-Microsoft is that it's my preference to first try the stock solution, and then later try the alternatives with the benefit of that experience. Also, I've had the rare positive experience with SourceSafe. Or, maybe I'm just a closet MS fanboy. :-)
Also, does the picture change at all when VS2010 comes out?
Thanks!
P.S. I'm downloading VisualSVN now to give that a shot since there's no reason not to.
If you qualify for BizSpark, that comes with TFS.
Given you are an independent developer, and although I fully understand you wish to go the full-on Microsoft route, I can't stress highly enough that using one over the other won't mean as much to you at this point.
When I started using Source Control, I used VSS... much like many others on this site. After about 4 months, I quickly realized that there were many issues with it (namely, that it corrupted every 10 days or so, and that it caused my machine to lag horribly.)
I switched over to SVN and I do have to admit, I'm quite happy with the outcome. When you build your devleopment team to 2,3,4,5... then look into the expense. You'll find that you can get the same affect of Team Suite if you integrate SVN with something like fogbugz, or look at something like CodeSpaces
If you are a solo developer you might not need to go the TFS way. As the product name suggests it is for teams. I suggest take a dive into source control systems like Subversion + TortoiseSVN or Mercurial + TortoiseHg. You could even use a web based source control if it fits your needs, sometime like Launchpad.net
If you would say why you are so hip on getting it from Microsoft, we might better be able to help you?
Give SVN a try. Look at TortoiseSVN, AnkhSVN, and Visual SVN.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Background: I'm a windows developer at MegaCorp(tm) and I am getting new hardware soon.
Question: Are there best practices around setting up my developer software installs?
Details: I've got my main IDE (Visual Studio/SQL Management Studio), but there are also tools that I'm testing out, additional tools I can't live without, and future accomodations.
All my code is stored on a remote server in SourceSafe so I don't need to really accommodate for that, but I'll regularly jump into perl/python/php for separate/side tasks.
The only advice I can give you is set up your machine in a way you need it and you can work with and then save an image so that you can return to that state easily.
Also, don't forget to go and get all your SysInternals goodies. Oh, also remember to export your rss feeds before you upgrade.
You should also install the Windows SDK (which usually doesn't come with VS), as there are many useful tools there that can help during development.
If you plan to use .NET, look into Reflector and LINQPad.
If you plan to use ASP.NET or do any web development at all, look into Fiddler and Firebug
Use a VM image, then the project has a VM image that is version controlled.
Tools and OS are recoverable years later.
Your name will shine on asa voice of sanity and configuration management.
Get rid of SourceSafe
Seriously, don't store anything in SourceSafe. There are many other, better Version Management Systems out there. What's wrong with SourceSafe? I strongly urge you to consider reading the following posts:
http://www.codinghorror.com/blog/archives/000660.html
http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html
Especially the last one - it goes into lots of detail about the problems with VisualSourceSafe. What should you use instead? Wikipedia has a great comparison of many different Version Management Systems for you to compare. You can look here to find out which ones integrate nicely with Visual Studio.
vim - VI Improved
Beyond Compare - best diff tool.
If you use multiple machines (like
one for dev one for test)
Synergy is invaluable.
If you occasionally need to edit
icons Paint.NET is pretty good.
As everyone else says kill source safe.
I have to agree regarding SourceSafe, whether or not you have the ability to opt-out of using it or not will obviously affect your ability to addopt a new SCM tool but if you can I highly recommenf the free VisualSVN Server for managing subversion and / or hosting repositories.
If you are prepared to pay for the licence you can also buy the VisualSVN plugin for visual studio, as a student I can't afford that but I have used AnkhSVN which integrates with VS through the source control provider APIs providing a nice native looking interface in VS 08
Other tools I can't live without:
TestDriven.NET
DocProject for easy generation of MSDN-style code documentation. I believe it uses sandcastle to do the real work but sandcastle itself is difficult to use and this is the most sane UI over it I've seen and managed to get working without massive amounts of work.
Paint.NET for graphics work
TortoiseSVN is another really good SVN client that I use for doing things like merging to trunk because I am more familiar with the interface and I think it's nicer than AnkhSVN in some areas
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am a very new programmer, I have made a couple basic applications, however I was told that it would be good to get used to using "source control" at the near the beginning of learning so I get accustomed to it. I have gathered that source control is what is used to manage programs with multiple programmers and that it is somehow connected directly to my projects in Visual studio. I also believe there are two primary versions, "TFS" and "SVN". Past that I am fairly lost, I am not sure what I need to actually implement this, specifically how I would do so on my personal projects. Also I don't know what program(s) are needed.
Should I use TFS or SVN?
What program(s) do I need to install?
How do I implement them in Visual Studio?
Is it a good habit to get into for my personal programming or would you disagree?
Please go ahead and open up wikipedia, you have a bit of reading to do:
Revision control
Subversion
With that reading done, you should have a better understand of what source control is. As a programmer, I'm pretty sure you'll find it makes sense to "save" what you're working on, making changes incrementally and being able to go back to those changes.
In a nutshell, revision control is the ability to go back in time, so that you can read code you have written at that moment.
Ok first there are many source control products other than the two you have mentioned but I would get used to SVN first.
TFS is expensive and tied into the Microsoft stack.
I'd start with reading this:
http://svnbook.red-bean.com/
Specifically the chapter on fundamental concepts
Yes this book is tied in to svn but it covers the basics too.
When you have read that download TortoiseSVN. This is an svn client that hooks into your windows shell. Only when you are comfortable with using this would I then move on to an integrated svn client. (I actually don't use one) AknhSVN is free.
The source control system is separate from your IDE. You can use it from the command line, or from a graphical client as well as from your IDE.
What you should know about a source control system is this:
you save your increment changes to the SCM (source code management), and each save receives an unique id/revision
you can retrieve any revision on any time, therefore changes are never lost
this gives you the liberty to delete unused code, debug info, or to refactor existing functionalities
and most importantly, it gives these functionalities to all members of a team, so that the team can work at the same time on the same code base, from their own development machines
You could start with svn, as it's very popular (especially for open source projects) with widespread support. You can gen the command line client from here:
http://subversion.tigris.org/
This is a nice graphical interface (windows):
http://tortoisesvn.net/
This is a free book to help you start with svn:
http://svnbook.red-bean.com/
If you need to setup a server on your development machine, this tutorial should help:
http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/16/Setting_up_a_Subversion_Server_under_Windows.aspx
check out Git and think about hosting your projects on https://github.com/ - also, check out linus talk on git: http://www.youtube.com/watch?v=4XpnKHJAok8
there are many different source control providers including TFS, Subversion (SVN), Perforce, CVS and Visual Source Safe to name but a few. It is also one of those areas that people tend to get semi-religous on, so I'll tread carefully!
I think most people would agree that Visual Source Safe is not the way to. It is fairly simple as a source control system but would do little to teach you about source control in general. TFS, SVN and Perforce tend to get pretty good feedback from their users.
Out of these, SVN is the only one that is free, so if you are planning to do this as a learning exercise, I'd be inclined to start there [actually I believe you can get a free 2 user license for Perforce too, but I'm not 100% sure on that). You can learn all the basics with this, as well as more advanced areas such as branching and merging.
If you do give it a go, I recommend you download SVN itself, and the TortoiseSVN client for Windows Explorer (I'm assuming you are on Windows here as you mention Visual Studio). You may also want to look at source control integration into Visual Studio, in which case I use VisualSVN (there is a free trial), but there is another popular one whose name eludes me (someone will hopefully add it as a comment).
Additionally there is a great, free, e-book for SVN, available (here)
Overall - to answer your specific questions:
Should I use TFS or SVN?
SVN
What program(s) do I need to install?
SVN itself (the server) and TortoiseSVN
How do I implement them in Visual
Studio?
Use VisualSVN or another SVN for Visual Studio client. You don't need this to learn source control, but it is well worth trying it out from in the IDE.
Is it a good habit to get into for my
personal programming or would you
disagree?
Yes, definitely!
Good luck, and hope you enjoy getting into source control.
Of the source control systems I've used Subversion with Tortoise is my preferred choice (I've used VSS, Subversion (SVN) and TFS).
Subversion has some excellent documentation on how it works and also on the general concepts of version control so that you actually understand what you are doind and why.
If you want to set up Subversion on a Windows stack then by far the easiest way is with VisualSVN which is free. The client side plug in to Visual Studio, however, is not free. But there are many free alternatives such as Tortoise.
You should not usually host your own subversion/git/whatever server. It is time consuming and error prone. For small projects subversion and git hosting can be found for free, and give you offsite backup, the ability to work from anywhere and the ability to add offsite programmers to a project with ease. If your needs grow, you can pay a small monthly fee.
You can use a google search to find candidates. The one I use is http://unfuddle.com.
I found this article to be very clear. (It recommends SVN).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My development team uses source safe at a very basic level. We're moving into some more advanced and extended development cycles and I can't help but think that not using branching and merging in order to manage changes is going to be biting us very soon.
What arguments did you find most useful in order to convince your team to move to a better solution like SVN?
What programs did you use to bridge the functionality gap so that the team wouldn't miss the ide sourcesafe integration?
Or should I just accept sourcesafe and attempt to shoehorn better practices into it?
Reliability
SVN is a lot more reliable with large databases
SVN is still actively supported
Atomic commit - in VSS when you get latest version while another user is performing checkin, you can get an inconsistent state, forcing you to repeat the "Get latest version" in better case, but sometimes when unlucky you may be left with a codebase which compiles but does not work. This cannot happen in SVN thanks to atomic commits.
Features
SVN branch/merge is a lot better
SVN has builtin support for remote access
SVN is more configurable (integration of external Diff/Merge tools)
SVN is more extensible (hooks)
Better productivity
SVN "Update" is a lot faster compared to SS "Get latest version"
SVN command line is a lot easier and cleaner - this is useful for automated build or testing tools
Same level of IDE Integration
VSS had a lot better VS integration until recently, but with AnkhSVN 2.0 this is no longer true.
Open
SVN is open and there is plenty of various tools using SVN or cooperating with it. Some examples include:
integration with many bug tracker or product cycle management products
shell integration
integration into various products
various management and analysis tools
source is available, you can adjust it to your need, fix the problems (or hire someone to do it for you) should the need arise
Cost
You do not have to pay any license or maintenance fees
First, teach them how to use SourceSafe in an efficient way.
If they are smart enough, they will begin to love the advantages of using a version-control system, and if so, they will soon reach the limits of SourceSafe. That's where they will be the more able to listen to your arguments for switching to a better VCS, could it be a CVCS or a DVCS, depending on what's the team is ready to achieve.
If you try to force them to use another VCS when they use SourceSafe in a wrong way, like saving zip file of source code (don't laugh, that's how they were acting in my company two years ago), they will be completly reluctant to any argumentation, as good as it could be.
Find some excuse to start using non-ASCII characters in your C# code (Chinese and Japanese are excellent for this).
SourceSafe doesn't like Unicode (even though Visual Studio does), so if you choose the right Unicode text and check a file in and back out, your entire file will appear as corrupted gibberish. The beauty of this is that because SS uses a "diff" versioning system, this actually corrupts the file all the way back to the original check-in version, and can't be fixed automatically.
When this happens just one time (as it did to me when working on an application that had to support Japanese), you will probably find it to be a decisive argument in favor of dropping SourceSafe.
There were two features that we used to sell management and the team on SVN over VSS.
1) The ability to branch. When using VSS, when a release was scheduled to go out, the entire repository was locked until the release actually went out. This included the test and fix cycle. So, developers were unable to commit anything other than fixes for the release to the VSS repository. This resulted in long integration sessions immediately following each release. With the use of release branches in SVN, there is no longer any need to lock the entire repository.
2) The ability to rollback an entire change at once. Because SVN records all files changed in a single, atomic commit, it is trivial to revert a problematic change. In VSS, a developer had to go through the entire repository and find every file changed at about the same time and revert each change to each file individually. With SVN, this is as trivial as finding the relevant commit and hitting the "Revert Changes from this Commit" button in TortoiseSVN.
As a side note, we use TortoiseSVN and everyone loves the file overlay icons for seeing what has and has not changed.
Whatever you do, move slowly! Don't start talking to them about branching on Day 1 -- it will just put them off. I'm stereotyping VSS users with that comment, but that's what I see out there.
For the developers: sell it as a replacement for VSS that works better and faster. Use VisualSVN on Day 1 so they have a super-shallow learning curve. Sell them on it being the same except faster, more stable, and 2 people can edit the same file and they won't have problems with some guy being off sick with locks on a bunch of files.
For the admins: sell them on it being more stable and easier to administer than VSS. Show them VisualSVN server.
Good luck!
First, document all the problems you are having that can be traced to root causes within the source control system. Keep track of them for a month or so. Add on top of that missed opportunities resulting from not using it. (if you say "opportunity costs of not using subversion" you may impress an MBA-type manager). These numbers are actually an understimate of the opportunity cost because presumably you could have been doing work that provides more than your hourly bill rate of value if you weren't messing around with VSS.
For example, do you have problems where files are locked that need to be accessed by more than one person?
Have you had problems with partial (non-atomic) check-ins?
Do you have problems where it is difficult for you to keep track of releases of the software and recreate the repository as it was in the past?
Do you have problems getting a copy of the code onto a server that doesn't have a sourcesafe client?
Do you have problems automating your build and testing process because continuous integration tools can't monitor your version control systems for updates?
I am sure you can think of many others.
If you can figure out the approximate time/money costs of problems caused by sourcesafe and benefits of things that subversion provides (using a generic number like $100/hr for labor costs or just hours) and any costs of late delivery of projects, do so. If you have collected data for a month or so, you can show the benefit using subversion per month.
Then present the approximate time/cost of moving to subversion. (About 8 hours to setup and migrate code, and 2 hours per developer to connect, checkout and move projects, something like that) The risk is low, since sourcesafe is still there to rollback to.
If the cost is more than the monthly benefit, you can divide the cost by the benefit to figure out the recovery period. You should also total it up over 3 years or so to show the long term benefit. Again, emphasize that the real opportunity cost is not directly calculable because you could have been adding value during the time you were trying to manage non-branched releases in sourcesafe.
Nobody recommends using SourceSafe any more, not even Microsoft. They will now offer you an (expensive) TFS licence instead. SourceSafe is just not reliable.
I wrote about it here: Visual SourceSafe on E2. It's a bit of a rant, but that's because I had to use SourceSafe for quite a while, and the memory makes me froth at the mouth a bit.
Reliablity is the big one that will bite you. But also there are features that you may appreciate in SVN or TFS:
TFS and SVN both have atomic commits of multiple files, but Sourcesafe does not - if you check in two files "at once", it's not one operation, it's the same as checking in one of the files, then checking in the other. You can get at the state in between, where one file has been checked in, but not the other.
SourceSafe does not keep history of deleted files, file moves or renames.
Contrary to initial impressions, SourceSafe does support multiple simultaneous checkouts of the same file, if you set the right options. But TFS and especially SVN are better designed for this way of working
Unlike SourceSafe, TFS and SVN both work fine against servers on the internet (TFS just OK, SVN excellently) and SVN works well offline - e.g. if you have a laptop on a plane or train and no 'net, you can still work and compare to previous revisions or even revert, since the data to do that is held locally.
As someone else pointed out, SourceSafe, like CVS, is a "dead" product. It is not being actively developed. TFS and SVN will have next versions out some time in the future.
First search google for the sheer quantity of pages describing how bad VSS is and share that with your coworkers.
Second, skip subversion and go straight to a proper distributed SCM like git or mercurial. Because merging is such an inherent part of distributed SCMs, they have to handle merges much better than centralized systems like svn. Subversion is still trying to retrofit itself to handle branching better, where the distributed systems were built correctly to begin with.
The AnkhSVN plugin for VS is pretty good. It's got a few oddities but on the whole works well.
Convincing the team to move is hard work - I never managed it :-( Probably one of the more practical arguments though is speed - VSS is s-l-o-w when you've got a 1GB source database and several users.
edit It's been so long since I used VSS I forgot it was locking! Yes, as mentioned here the ability to move to a non-exclusive/merge changes model should help if you've got more than a handful of developers. It saves yelling "Can somebody check in the common includes" across the office!
You say "What arguments did you find most useful in order to convince your team to move to a better solution like SVN?"
If you don't know that it's a better solution, then why are you making the arguments? If your mind is made up enough to go argue for a solution, you should know what those reasons are already.
What convinced you that you should move to something better? Those are your arguments right there. Anything short of those arguments will sound like it's just an issue of personal preference.
TortoiseSvn (free) is really nice for explorer integration, giving you all the features of svn from a context menu.
VisualSvn (commercial) makes it just as easy to integrate svn into Visual Studio, with the same status indication in the solution browser as well as context menus to use all the subversion features.
Both these tools go a long way to making version control seamless. It's been a coupe of years since I dealt with VSS, but these tools are a way nicer way to use source control.
Ditto for what every one has said about VSS being poop
Subversion has good support for branching and doing merges... I don't remember VSS having any capabilities in this department at all. I do remember teams going through pain of week long merges when needing to release from VSS, pain which just doesn't exist anymore with Subversion.
Build some automation that mirrors the VSS repository into a SVN repository
It takes time to build a consensus. If your SVN mirror of the VSS repository is available at all times, it will be easier to accumulate converts. The mirror doesn't have to be perfect- it just has to be usable. There are existing tools for this purpose.
Tell them to treat the source code as if it was money and point them to the numerous examples of SourceSafe coming down in flames taking the source with it. Things like that are just not supposed to happen in a proper source control system.
The best argument against SourceSafe is that it is just isn't Safe, everything else can potentially be called "features we don't need".
The clincher for us was the speed (i.e., the lack thereof) of VSS over VPN and low bandwidth hotel networks on the road and the problems of trying to tunnel through firewalls so that two teams at two different sites could quickly, securely, and reliably work from the same code repository. We were running two VSS repositories and packaging up "deliveries" that had to be merged into the other site's repository to keep them in sync.
The team grumbled for a while, but quickly got over it. TortoiseSVN is fantastic by itself and the AnkhSVN plug-in for Visual Studio really eased everyone into the changeover.
Looking back, I can't believe how many "Can you check in file SoAndSo?" e-mails we sent around, not to mention the "SourceSafe is down. We've got to restore the repository" e-mails.
Sheesh. After reading this comments and writing this response, I can't believe we put up with VSS for as long as we did.
Web page summarising problems with VSS - just point people to that URL
If you use VisualSVN the team won't miss VSS as much. 2 people being able to work on one file at the same time is a big selling point too.
The unreliability of source safe ("please fix the repository...") was enough of a sell for us. Andecdotally (I've never measured it) SVN also always seems faster. Good concurrent checkouts / merging.
I'd always figured that to a developer it was almost too obvious. SourceSafe just seems to break and die all too often to not want to replace it...
Tell them to read this http://www.highprogrammer.com/alan/windev/sourcesafe.html
I would recommend that you go ahead and start introducing best practices to your sourcesafe usage with a view to changing to subversion further down the line. Hopefully this will make your actual subversion migration easier and give you time to sort plan out your development cycles, branching strategies et al. properly.
The other thing to consider is your development process in general. A source control management system is only ever part of the solution, to get the most out of subversion or any other product you will probably want to look at how it's usage interacts with your code review, qa and build processes.
I don't remember any SourceSafe user ever liking the product. Do your colleagues actually like it?
I've got a similar issue with CVS at my current customer's usage. Since "it works" and they are mostly pleased with it, I cannot push them to change. But daily I sure wish they would!
When I was at the launch for VS2005 I managed to corner a Microsofty and ask why SourceSafe was so awful to use. The reply I got was rather shocking, not just because of what he said but because he was so up front about what he'd said.
He told me that it was only really meant for one person to use and even then it wasn't very good at doing that.
My colleagues and I were a bit shocked we couldn't think of much else to do other than laugh out loud, as did the Microsofty! He then told us that it wasn't used internally.
So, we switched to subversion shortly after that. We'd pretty much decided to go for it before the launch event, but that just confirmed we'd made the right decision.
We used to use SourceSafe. Then, when I joined the team I was in a different location and even though we have a fairly good LAN when I tried to check out the latest version it took 40 minutes. I persuaded them to convert to CVS (we now use SVN) and the checkout time dropped to a couple of minutes. SourceSafe was just too slow to be usable at a remote location.
We moved from SourceSafe to Source Gear Vault. This source control engine is very comfortable for some one used to SourceSafe. We finally decided to make the change after a couple SourceSafe corruption incidents, that came at critical times. So my advice would be to focus your sales presentation on SourceSafes unreliability.
Surely using source safe is enough reason to want to migrate to another source control system?
I used SVN and CVS at my old job and have moved to a company that uses Source safe (we are going to migrate to SVN) and just using VSS has been enough for me to take a serious dislike to it. I went in with an open mind, despite many of my colleagues from my previous job telling me horror stories about VSS I assumed that it would have gotten better since they used it.
Not being able to edit a file because somone else is/was editing it is ridiculous. I've tried to move to more distributed versioning systems like Bazzar which is made by cannonical however it's not mature enough in terms of the tools available.
Source safe gets in the way of development where SVN helps you almost every step of the way.
Plus Using tortoise Svn made code reviews a lot easier.
Only to the extend as you are able to herd a bunch of cats. I've been there twice and in both cases it took some serious problems in Source Safe before people saw the light. As a manager on the other hand I simply directed the team to use SVN and our productivity increased by 300% ( this was working with a group in India and in the US. We had code exchanges that used to take a long time before svn )
Also Trac mounts on top of Subversion. It's free and a great way to view the repository (timeline, wiki, etc)
As you're making these arguments, consider whether you need to address any policy your company may have about using open source tools. See this answer to a prior question: Switching source control
Make them use it and they will switch to something else :)
Now, being serious, tell them its not that hard to use it, many developers that I've known refused to switch because they related subversion to unix and wierd commands, show them interfaces like ToirtoiseSVN or VisualSVN, tell them that Subversion allows them to edit the same file withouth a forced locking like VSS does.
And last but not least, it is Open Source. It has lower cost than buying Team Foundation Server and if you look around you will see that small teams of developers work quite well with SVN.
I used SourceSafe on a small development team and was responsible for keeping it running.
I found the database gets corrupted pretty easily, and there isn't much recourse when that happens. The "repair" feature (as with most any Microsoft repair feature) just doesn't work 98% of the time.
Naturally, when our database became corrupt, we tried to restore from our backup archive. That was when we discovered the other bad thing about SourceSafe: its 2GB archive limit. We were making backups at our office for months before we ever realized that they couldn't be restored and were useless.
SourceSafe is just a disaster waiting to happen.
I'm planning on ditching SourceSafe in the next few weeks, after over a decade of putting up with it. Mostly I've been using it within the context of a small (< 5 person) team, and not had to do a lot of branching because there's been no call to do it.
However, the #1 problem for me, and always has been, is that the damn thing is so prone to corruption - if you have your SS database (lol, database; collection of randomly named files more accurately describes it) on a network drive, and something happens to your LAN connection partway through an add/checkin operation - 9 times out of ten you get "invalid handle" and the damn thing is corrupted in some way, and then you get to play Russian Roulette with the Analyzer tool.
I realised, a couple of months back, that for the past decade I had been making local zipped up copies of the source at every release of the software I was working on, because I didn't trust the source control system. What a waste of time.
So, it's going. I'll probably use Subversion and TortoiseSVN, because I think the team will need a UI to ease the transition.