0

As stated in the title, my agency (also whole software department of my company) still use Visual SourceSafe 2005 as Version Control System.

My company is a hardware manufacturer for over 5 decades, and software development have started for nearly 2 decades. Just only my agency there are 30 developers, and the head office have even more devs. My agency VSS database is around 133 GB and the head office is more than 200 GB.

I've also skimmed through Google:

I also know that extended support of VSS will end at July 11 2017. I also verified many things listed in the articles (lack of atomic checkins, poor branching/merging, binary files trouble, slow history, etc.). For example, I just status search through whole agency database (I can't check HQ since permissions):

  • 55 "File names.dat maybe corrupt. Ask your SourceSafe administrator to run Analyse utility on this database."

  • 5 "Error reading files."

  • 1 "VSS/data/terqeaaa.b not found."

Is the situation of database bad? If it's right, then, how can I convince them to switch to other VCS? I need some reliable recently information and some evidence. The guide how to show/proof them is better.

I asked the admin to run Analyze but he ignored my words since I just started to work for a few months. People can see VSS basic weakness. They also complain "who check out this file?" and resolve conflicts by barehands. They have to use WinMerge to diff and compare, Get latest version instead of branching and checking out, never comment orsee history log, create entire new folder for new code, etc. However, they do not give up on SourceSafe. (They are using Visual Studio 2012 to develop and didn't notice Team Foundation Server).

Community
  • 1
  • 1
khôi nguyễn
  • 626
  • 6
  • 15

1 Answers1

0

I think you already summed up many of the reasons:

  • VSS is already in extended support and is only kept secure, but barely functioning. It's on life support in the palliative care ward. Extended support, in the real world means unsupported. Unless you have a very strong credit limit, Microsoft will not help you if it turns out you need the support.

  • VSS officially supports only the following operating systems, none of which are currently supported anymore: Windows XP, Windows 2000, Windows NT 4.0 with SP6 or later, Windows Server 2003.

  • It hasn't has any improvements, fixes since 2008.
  • The Visual Studio and TFS documentation have been advocating the migration to TFS since 2008. There has been a full migration tool since 2012.
  • It has known issues with stability, internal consistency and corruption. A conscience administrator will need to spend regular time to ensure internal stability and consistency.
  • It doesn't support modern development workflows (transactional commits, distributed version control, modern branch/merge, cherry picking, optimistic locking etc).
  • It has a very limited security capacity, users with access to the share can simply grab the whole file share and force access.
  • It's not useful for remote access. Or at least requires VPN and a stable, very fast network connection. Even then it'll likely increase the chance for corruption.
  • The user experience in Visual Studio and other tools that directly support TFVC or Git is much, much better.
  • Cross platform support is non-existent. In the current market this is becoming more and more important.
  • The standard backup (archive) tool built-into the product has a limit of 2GB repositories.
  • Microsoft recommends at least weekly analysis of the sourcesafe database and recommends the logs and backups of the repo to be kept so corruptions can be manually be put back together by copying files from the backup back to the active share.

There is a supported migration path from VSS to TFS.

A migration to TFS brings more, ability for Continuous Integration, Release Management, Work Management (Agile tooling, backlogs), Test Management on top of a much more stable, performant and secure backend that makes use of the qualities of SQL Server for robustness, integrity and security.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • Thanks a lot. Could you please to share any experience/knowledge to show some critical errors in practice? I doubt they will keep VSS unless the real trouble come. In the given example, I found some abnormal, but I can't run the Analyze to show present errors since I'm not the VSS admin. I also don't have enough knowledge to prove that the error will happen again and get worse. – khôi nguyễn Nov 18 '16 at 15:25
  • 1
    The problem with the kind of corruptions is that they are generally irreversible and can cause massive data loss. Running analyze and analyze and fix just often just resets the baseline, but any corrupted data is lost. I've seen vsts databases going from working just fine to fully broken from one moment to the other. Especially flakes network connections can cause mayhem. Search SO and sever fault and you'll likely find many people with corruptions ranging from single files to whole databases. VSS just wasn't built to prevent these kinds of problems. It just helps you detect them. – jessehouwing Nov 18 '16 at 15:32
  • In general the best solution to all problems is to restore the whole database from backup. – jessehouwing Nov 18 '16 at 15:35
  • I read from somewhere that it can't restore if the database is over 2GB, is it right? I mentioned the "huge" database in question description. – khôi nguyễn Nov 18 '16 at 15:36
  • 1
    Around 2003 or so, I collected some tenths known defects of VSS, published in MS KB. – Giulio Vian Nov 18 '16 at 15:39
  • 1
    From the docs: Under normal use, your Visual SourceSafe database should not exceed 3 to 5 GB. https://msdn.microsoft.com/en-us/library/bb509342(v=vs.80).aspx. More on the analyze frequency: https://msdn.microsoft.com/en-us/library/bb509342(v=vs.80).aspx. Backup and restore limits: http://stackoverflow.com/a/288122/736079 – jessehouwing Nov 18 '16 at 15:40
  • Thanks all for advice. Hope I can do a better thing. @jessehouwing It's useful link but seems it's duplicated. – khôi nguyễn Nov 18 '16 at 15:46
  • It's the same doc :) – jessehouwing Nov 18 '16 at 15:48