27

Having spent all morning trying to check something in - I now realise I've lost a couple of days worth of work.

Its happened before - and is apparently common occurrence with SourceSafe. Can SourceSafe be used successfully, without problems, and if so, how?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
billy.bob
  • 6,549
  • 4
  • 29
  • 45
  • 42
    Oh dear God NO ... never, ever again! – Tim Post Dec 09 '10 at 13:22
  • 2
    Possible Duplicate: http://programmers.stackexchange.com/questions/19085/have-you-ever-been-really-badly-burned-by-vss – Bobby Dec 09 '10 at 13:22
  • 28
    I fought long and hard to get SourceSafe out of my company. Eventually won and everyone is happier for it. – Kevin D Dec 09 '10 at 13:52
  • 14
    Any organization using VSS is a bad "org smell" – JoelFan Dec 09 '10 at 15:45
  • Do all of these other versions still work with Visual Studio? – billy.bob Dec 09 '10 at 16:09
  • 2
    Sourcesafe has its issues, but based on your scenario I am hesitant to blame it for your data loss. Sounds like a configuration or process problem. – JohnFx Dec 09 '10 at 16:45
  • 9
    The phrase "Checking in early and often." is to prevent these kinds of situations. You should never lose more than a few hours of work. However, Iron Maiden said it best about VSS: "Run to the hills! Run for your life!" – Ryan Hayes Dec 09 '10 at 17:46
  • @dave.b the short answer is that a you will need a scc plug in to work in side visual studio like source safe did. for subversion there is ankhsvn http://ankhsvn.open.collab.net/ Mercurial has VisualHG at http://visualhg.codeplex.com/ – mangelo Dec 09 '10 at 17:59
  • 3
    *Microsoft* doesn't use it. Why should we? – greyfade Dec 10 '10 at 05:42
  • 1
    I've used many version control systems over the last twenty years. SourceSafe is the only one that lost revisions in a manner that wasn't attributable to user error. – Gort the Robot Nov 05 '12 at 22:38

18 Answers18

45

My view is simple, migrate to something else ASAP. It won't take long (1-2 weeks WAG) and no matter how long the migration takes, it's easy to cost justify that to management. A little time to migrate equates to solid source control and very little chance of lost source code. Do a quick google search for "source safe horror stories" or similar if your boss is skeptic.

DevSolo
  • 2,814
  • 20
  • 23
  • True, but sometimes it isn't easy to justify to a non-technical person spending 1-2 weeks migrating the source control. – t3mujin Dec 09 '10 at 16:38
  • 2
    @t3mujin, see the discussion on "technical debt" http://programmers.stackexchange.com/questions/18059/how-do-you-explain-refactoring-to-a-non-technical-person/18184#18184 – Nemi Dec 09 '10 at 16:52
  • SourceSafe is an active and on-going liability to your short-term and long-term productivity. It can easily be replaced by any number of modern, safe and distributed version control systems. Do some research with Google on SourceSafe horror stories as well as professional guidance. MAKE YOUR CASE STRONGLY. Do whatever it takes. – Adam Crossland Dec 09 '10 at 18:05
  • 3
    @t3mujin: migrate it project-by-project. Where I'm working, we used to use SourceSafe, now we use TFS. Migrating everything (hundreds of projects) would have been a pain, so instead, if we have work to do on an old project still in SourceSafe, we first spend the small amount of time migrating it, and only then start work. – Carson63000 Dec 10 '10 at 00:23
  • @Carson63000 We are using TFS for most current projects, but there's a large source base with few but occasional updates on VSS that no one's willing to pay the migration to TFS. I'm not on the team that uses it more often so I'm OK with a few lines of code once in a while – t3mujin Dec 10 '10 at 01:37
  • For those of you who search for VSS and find this, I suggest reading [VSS: unsafe at any speed](http://www.developsense.com/testing/VSSDefects.html). The article details how to *reliably* and *repeatably* cause source safe to delete/corrupt your files. – Spencer Rathbun Mar 15 '12 at 19:53
33

Worst. SCM. Ever.

All that is wrong in SCM is embodied in VSS. Even StarTeam is better than Source Safe. Source Safe is the Internet Explorer 1 of the version control world: entirely superceded by any other implementation.

How did I use it?

My typical workflow for getting things done was

  1. Check out the project
  2. Lock all the files (to avoid merging with anyone 'cos that opened the unholy gates of Hell)
  3. Did my work
  4. Each day checked my changes in
  5. Checked it all back out again and fixed all the problems with integration
  6. Checked it back in

In comparison to Subversion, the above is laughable (apart from checking you've not broken the build).

Restrictions to my team's programming practices

These are the rules the team had to work under to make it work for us. Your mileage may vary.

  1. One person only may edit a file (Heaven help you if they go on holiday)
  2. Do not branch it's too hard to manage
  3. Never attempt to go back to a previous revision

What can be done?

Polarion has a good set of tools for migrating from the likes of Source Safe into Subversion (SVN) which is the current de facto standard within most enterprises for open source version control. Subversion does suffer from requiring a server to be available to allow checkins (unlike GIT or Mercurial which are designed for distributed offline teams).

Gary
  • 24,420
  • 9
  • 63
  • 108
  • @David don't get me started on attempting to get file revision histories or branching (I'm weeping as I write - so many wasted hours of my life...) – Gary Dec 09 '10 at 13:43
  • 2
    yeah, branch and merge aren't really fun in a good SCM. I don't think congress would allow you to make people do it in sourcesafe. – BlackICE Dec 09 '10 at 13:46
  • 2
    Never go back to a previous version? Why not? And if so, what is the whole purpose of using a SCM tool? – JoelFan Dec 09 '10 at 15:44
  • Back in the day when I was at a shop that used VSS we never had any trouble at all going back to an old version. That seems a bit extreme. I'm with you on branching though. – JohnFx Dec 09 '10 at 16:46
  • @JohnFx @SpashHit Our team had a very low tolerance for pain so maybe I'm being a little over the top. When Subversion came along it was like a mighty weight had been lifted. – Gary Dec 09 '10 at 17:11
15

Change your Source Control to SVN/Mercurial/Git and never look back!

Gary
  • 24,420
  • 9
  • 63
  • 108
Amir Rezaei
  • 10,938
  • 6
  • 61
  • 86
11

We took it out of operation about a year ago.

It happened several times that what I'd checked-in on the previous evening just wasn't there the next morning. I didn't find that amusing because it looked suspiciously like I just hadn't finished my work. Since I was new to the company then it might have been dangerous to me.

We them moved on to the TFS and it's been operating smoothly ever since.

9

My view?

There's better ones that are easier to use, safer to use, and are completely free. Why bother using it at all?

This is one area of development where we have plenty of choice; most, or all, better than VSS.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
9

Using SourceSafe in a commercial operation is like heating the building by burning dollar bills.

In 2000, my eight-developer company probably lost 5-10% of its productivity because of the twice-daily-on-average corruptions of VSS databases. It was only that low because we'd gone to hourly backups.

Since moving away from VSS to Perforce, svn, and git, I've never had an SCM database become corrupted.

Bob Murphy
  • 16,028
  • 3
  • 51
  • 77
7

I may get down voted to hell on this, but ..

alt text

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.

Please, don't use it, ever.

Tim Post
  • 18,757
  • 2
  • 57
  • 101
  • You're unlikely to be voted down. My only criticism is that cyanide is obviously the drug of choice for the habitual VSS user. – Orbling Dec 10 '10 at 00:04
7

used it for years - it was the default solution, as it was already there. Had it bite me quite a few times, but inertia is difficult to overcome

then i had to use it remotely over VPN, and even minor check-ins were like stuffing a brick through a pinhole. 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.

Never going back.

Community
  • 1
Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • Source Offsite was for that. I remember that well also. I actually bought my own copy of source offsite just so I didn't have to do VSS over the VPN – BlackICE Dec 09 '10 at 19:28
  • +1 for "I no longer fear branching" the sign of a mature SCM – Gary Dec 09 '10 at 21:15
5

It's an abomination. But still better than nothing.

BlackICE
  • 2,425
  • 1
  • 18
  • 24
  • 12
    With all the alternatives, it's hard to justify using, because when it goes south, that's what you'll have: Nothing. – DevSolo Dec 09 '10 at 13:34
  • 1
    +1 for "better than nothing", with the understanding that getting the change history from a Win32 network drive based file system is only fractionally harder than getting it from VSS. – Gary Dec 09 '10 at 13:41
  • 13
    How can it be better than nothing if it causes you to lose work? – billy.bob Dec 09 '10 at 13:42
  • 4
    You can lose work with nothing as well, sourcesafe can at least save you _sometimes_. – BlackICE Dec 09 '10 at 13:47
  • People use SVN!! – Amir Rezaei Dec 09 '10 at 13:56
  • 1
    @Amir - to be honest if you're going to move now I'd take a look at Git or Mercurial over SVN. SVN is the simplest move (in that the paradigm is closest) but given that there is going to be an effort involved regardless, I'd look at newer potentially better options. – Jon Hopkins Dec 09 '10 at 14:04
  • 1
    I would sooner use CVS than VSS. That's how much I hate VSS. – Tim Post Dec 09 '10 at 14:25
  • 4
    @David - so can sensible backups before doing anything potentially 'icky'. The only thing that rivals VSS in failure is MS BOB. VSS is so horrid that a charity should be created in the name of curing people from using it. – Tim Post Dec 09 '10 at 14:27
  • 9
    No, it is worse than nothing. Because if you don't ALSO have backups, you have a false sense of security and can lose EVERYTHING – CaffGeek Dec 09 '10 at 15:01
  • @Chad no, I think everyone knows by now how much VSS sucks, there's no sense of security with it... – BlackICE Dec 09 '10 at 15:22
  • @Chad - Exactly - everyone seems to think their source is safe here! – billy.bob Dec 09 '10 at 15:55
  • 1
    all your source are belong to us! – BlackICE Dec 09 '10 at 18:51
  • Give me a bit of latitude here in my logic: The foundation for developing is an IDE which requires an OS. If that's the base then anything after that would be 'something'. If that OS is Windows 7, you have built-in backup (which is not 'something' because it's not an addition to the environment). Scheduled backup is better than VSS, thus nothing is still better than VSS. – Steven Evers Dec 10 '10 at 01:21
  • 1
    If as others have suggested, practically speaking it needs rules like don't branch, don't revert and only one person on a file at a time, I fail to see how it's of any value whatsoever. – Lawrence Dol Dec 10 '10 at 04:41
5

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.

Jon Hopkins
  • 22,734
  • 11
  • 90
  • 137
  • Were you working within a team, or on solo projects within an overall codebase? – Gary Dec 09 '10 at 13:42
  • Within a team though the code base was relatively well divided up in terms of who was working on what so there would rarely have been conflicts. – Jon Hopkins Dec 09 '10 at 13:44
  • @Jon That goes a long way towards explaining the trouble-free operation. – Gary Dec 09 '10 at 13:49
  • 1
    FWIW my experience is similar to Jon's. 7 years, 8 person team, no problems using VSS. Apparently we're in the (lucky) minority. I would never use it again based on all the stories (using SVN now). – Steve Fallows Dec 09 '10 at 13:59
  • I had a similar experience. We really didn't have any trouble until we had people accessing it over a WAN. It was very susceptible to issues over unreliable networks. – JohnFx Dec 09 '10 at 16:48
  • 1
    When branching, merging, and conflict resolution are considered complex operations, you're probably using the wrong version control system... – James Dec 10 '10 at 15:21
5

Even MS is deprecating it in favor of TFS.

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.

JohnFx
  • 19,052
  • 8
  • 65
  • 112
  • Getting people to start using SCM is good, no argument. But... VSS? Bad experiences can't just give a product a bad name, they can give a whole category a bad name. Or: how many devs starts SCM with VSS and then thought "Wow, this SCM stuff is as bad as I expected" when VSS screwed up? Not to mention that SCM is an *extremely* critical piece of infrastructure, meaning: bugs not allowed (yeah, I know...) – Jürgen A. Erhard Dec 09 '10 at 19:17
  • @jae that wasn't my experience. VSS was my first exposure to SCM and I've never looked back. I didn't experience any data loss, corruption or any problems whatsoever for YEARS while using it. I eventually moved on, but I think it would have taken me longer to integrate a tool if it hadn't come pre-installed with Visual Studio back in the day. – JohnFx Dec 09 '10 at 20:17
3

After 3 years of using it, complaining off and on to my manager because of all the more advanced/rational alternatives out there, I've never really had a problem with VSS, but I've never had an option either.

My views are that it both sucks and blows.

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.

Truly painful.

Peter Turner
  • 6,897
  • 1
  • 33
  • 57
3

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.

Jas
  • 6,254
  • 1
  • 31
  • 46
  • 1
    +1, putting "VSS proficiency" on a job ad is a sure sign that not only does the company use VSS, but that they have a setup where VSS is already so corrupted and problematic that it requires genuine VSS experience to make it work *at all*. – Carson63000 Dec 10 '10 at 00:36
1

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.

For kicks, just install GIT - point it at your VSS files and see how easy it is for GASP two programmers to work on different parts of the same file AT THE SAME TIME, and then have the software intelligently merge your changes... SCM tools should be more than just source backup.

Paddy
  • 2,623
  • 16
  • 17
0

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:

  • Very unreliable
  • Not usable branches
  • Very poor versioning support, you have labels but (just like branches) not really usable

I'm with all of the above: choose one of the waaaaay better open-source alternatives (even old CVS) or, if your company has some kind of MSDN subscription, TFS.

t3mujin
  • 141
  • 3
0
  • its default locking was slowing developers down, and no one wanted to mess with its setup
  • it doesn't integrate with other services very well, for example a project management web application
  • it was not going to work well with our planned CI server

The new 2010 Team Foundation stuff was supposed to help a lot, and try to get away from the bad parts of VSS. But at its core it still relies on VSS, which is why we moved to SVN.

edit - I understand that TFS is all new, but when testing it, multiple developers I asked had very similar feelings to it. The reason I said 'at its core' was because I remember looking at the files TFS made in my solution that looked just like those VSS made. This is from a developer standpoint, maybe not even knowing about the tech behind VSS or TFS or any other SCM. Sorry for any confusion.

jmlumpkin
  • 119
  • 5
  • What!?!? TFS does not anywhere rely on VSS – BlackICE Dec 09 '10 at 19:29
  • TFS was rewritten from the ground up... does not rely on VSS in any way. – LeWoody Dec 09 '10 at 21:04
  • 2
    Visual Studio uses the same SCC plugin API for TFS and VSS. This API supports VSS and has a VSS feel to it, so when you change from VSS to *any* other source control server, it will feel as if the ghost of VSS is still there. – MatthewMartin Dec 09 '10 at 21:17
  • The stuff it added to your solution and source folders (the files, etc), looked to be in the exact same format when I tried it before. – jmlumpkin Dec 09 '10 at 21:20
  • 1
    @LWoodyiii: Then how did they end up coding such a steaming pile of crap twice? They must have at least been reading the comments in the VSS source code. – Robert S Ciaccio Dec 10 '10 at 03:52
  • @calavera, Steaming pile of crap may be your opinion, but the fact is that the code is completely different. – LeWoody Dec 12 '10 at 04:51
  • @LWoodyiii: I don't dispute that it is. More of a philosophical question I guess. I apologize if it offends you, but I just don't get the never-ending cavalcade of bloatware spewing from Redmond. Whatever happend to keep it simple stupid? – Robert S Ciaccio Dec 12 '10 at 07:09
  • @calavera - TFS has the appearance of being "bloated" because it's not *just* a source control tool. It's an Application Lifecycle Management tool, which although includes source/version control and many people use it only for this, is also much, much more. (http://is.gd/j91v7) – CraigTP Dec 21 '10 at 12:27
  • 1
    @CraigTP: most develoopers have absolutely no need for the stuff in TFS. It's just noise that makes their job harder. If PM's and leads want all that functionality, they should separate from the software that a developer needs to use to be productive. – Robert S Ciaccio Dec 21 '10 at 17:25
  • @calavera - I don't disagree. If all you need is version control, even "basic" TFS is probably overkill, and overly complicated to get set up. In that case it's probably better to go with SVN or GIT or HG. That said, a "basic" TFS installation does give you version control, issue tracking and build automation in one "hit". This is something that probably most (good) developers/teams *do* have a need for. – CraigTP Dec 22 '10 at 11:16
0

Back in the day I was saddled with SCCS under XENIX. VSS, in Visual Studio 6, for all it's failures and problems had distinct advantages. I still use it for small projects and I no longer use SCCS in any version.

Dave
  • 427
  • 3
  • 7
0

I cannot figure out why everybody wants to badmouth VSS. VSS is not distributed, and distributed version control is

  1. better
  2. allows for non-distributed version control in practice

Please read this.

Dan Rosenstark
  • 2,344
  • 1
  • 20
  • 20