Click here to monitor SSC

Tony Davis

Simple-Talk Editor
News, views and good brews

The VSS Mess

Published Thursday, September 02, 2010 12:06 PM

Microsoft's Visual SourceSafe (VSS) will soon cease to exist. Mainstream support will end in April 2011, and so users will be forced to make the leap to an alternative: But which one?

Visual SourceSafe was bought by Microsoft to fill in a hole in their development IDE. It was originally a DOS command-line tool that was developed by another company in the late 80s as a rival to the then-dominant CVS and PVCS. It wasn't much good at what it did then, and has been in decline ever since. Even when it worked, its pessimistic check-in/edit/check-out locking model was fundamentally unsuited to large-scale, agile team developments and yet many dev teams still persevere with it, partly out of a desire for a source control system that is fully integrated into their IDE (Visual Studio), and partly because there is no obvious alternative.

They might choose the open-source Subversion (SVN). Its server-based architecture can be used on all platforms, such as Windows Mac, and Linux, and is widely adopted and supported among developers. SubVersion is a good, conventional, well-proven solution that is integrated into Visual Studio and SSMS via third-party plug-ins. It supports branching and merging, but only if you are uncharacteristically patient as a developer: for the rest of us, the temptation is always to avoid them in SVN in favour of the straight-line death-march.

With Git, the distributed Version Control system for the wild men of IT development, branching and merging is, by contrast, an integral part of the system. Every developer maintains his or her own local source repository and so every each developer has their own branch that they can work on without affecting other people. Git is rapidly gaining in popularity. Linus Torvalds, Git's creator, encourages the growth of a "network of trust" among developers, and a stronger determination to prove that a particular branch performs and scales better than another, and so should be pulled and merged by the rest of the team. It is free to use and surprisingly simple. However, no VSS or SSMS integration exists yet.

Microsoft developers will tolerate quirks in their Source Control system as long as it is integrated into the IDE and Team Foundation Server (TFS) would fit the bill perfectly. It is a complete collaboration package with version control, full integration with Visual Studio, SharePoint, reporting Services and so on. However, it has suffered in the past from four problems: It was expensive, handled merges awkwardly, had a painful installation ritual, and the upgrade path from VSS to TFS wasn't smooth enough.

This has changed with TFS 2010. Microsoft has made a great effort to improve TFS and make the migration path from VSS less painful. The new "slot mode" version control mechanism is designed to greatly improve the handling of merging, change history, code refactoring and so on. The install has been completely overhauled; demos at the recent Tech Ed conference were at pains to emphasize its new "20 minute" installation process. The limited workgroup edition has been replaced by a $500 "basic" edition, which is identical to the full edition, expect for reporting and SharePoint integration. The full edition is now only $500, with 5 free CALs, plus $500 per CAL for each non-MSDN user. Finally, a proper VSS to TFS migration path has been established. It's perhaps slightly more convoluted than one might have hoped; involving a number of preparatory steps, and some manual XML file manipulation, but it's a start.

Cheers,

Tony.

Comments

 

Phil Factor said:

I think it is slightly unkind to say that no Visual Studio integration exists for Git. There is a fairly active project called GitExtensions  on ...
http://code.google.com/p/gitextensions/
I have to admit that I haven't yet tried it out, so I'd be interested to hear if anyone has used it, or any other Git integration tools for Windows. Git extensions also does an equivalent service to TortoiseSVN with its' windows Explorer add-in.
September 3, 2010 7:45 PM
 

Matt Spradley said:

I agree that Microsoft made a mistake making TFS too complicated. You can tell it is targeted at the enterprise and did not really consider small teams. The disconnected story is really bad as well.

I have used VSS, SVN, TFS, and Mercurial. I really wanted to make TFS work and used it extensively in my previous company. It takes too much maintenance. I switched to Mercurial and have been very happy using it for the past year and a half.

There are some tools that provide Mercurial integration with the VS IDE but we don't use them. The model that Mercurial (and other DVCS) uses where you don't really check out anything makes IDE integration unnecessary in my opinion. The Tortoise HG shell extensions are all you really need. Also, Codeplex supports Mercurial now.

We have a really solid CI system going using Mercurial as the VCS and FogBugz as the bug tracking system. None of the tools require much admin. We would probably need a dedicated admin if we attempted the same thing with TFS.
September 4, 2010 12:41 PM
 

matthewkrieger said:

@Tony

Since the folks running VSS have generally run it for a very long time, they certainly aren't forced to move. The software isn't going away, just the support. I bet these folks haven't called support in years.
September 5, 2010 1:57 PM
 

cjlotz said:

I agree that TFS 2010 has become simpler but the whole on-line model is still problematic in my eyes.  The disconnect model of SVN or any other DVCS is a major benefit IMO - especially these days where more and more people are starting to working remotely.   Having worked in VSS, SVN and TFS I would say that a lot of teams opt for using TFS due to the fear of the unknown.  You'll typically find that teams migrate from VSS -> TFS and not from VSS -> SVN or any other DVCS due to concerns about administrating the server etc.  As the team matures over time you may find that they may consider moving over to SVN or DVCS.  I haven't spend a lot of time using a proper DVCS like Mercurial or Git, but the fact that it makes merging easier makes it very appealing.  Also, to make it easier to transition from TFS to Git or Mercurial, it will help greatly if you have plug-ins to VS to lure developers away as they are used to doing everything within VS itself.  VisualSVN plugs this gap very nicely for SVN.  I'm not sure the same level quality of plugin exists for Git or Mercurial.  I know about VisualHG and VisualGit, but can't vouch for the quality of the plugins.
September 8, 2010 6:15 AM
 

DrCodd said:

I think Microsoft have lost the source code to VSS ;-)

I really feel sorry for any developer out there who is still using VSS.  We migrated to www.purecm.com and haven't looked back.  So much better in every way.

Check it out.

September 8, 2010 6:19 AM
 

cjlotz said:

Interesting to see this morning that MS has donated $25 000 to the Mercurial project.  Seems like a lot of projects on CodePlex has started using Mercurial once CodePlex added support for it.  Here's the link:

http://blogs.msdn.com/b/codeplex/archive/2010/09/06/codeplex-com-donates-25-000-to-mercurial-project.aspx
September 8, 2010 7:44 AM
 

Sean Kearon said:

I've used TFS (05 & 08) daily in work since it's release and I use VisualSVN at night for my own work.  Have to say that SVN is far easier to use as a source control system and VisualSVN is very sweet to use from inside VS.  

The strength of TFS is in the integration of a number of application lifecycle services such as work item management, embedded process control, build management/CI etc.  This with being a string collaboration tool for all project stakeholders to use puts it into a different league.  To be fair, it is a huge amount more than just source control!

It's worth noting that there is a free Mercurial VS plugin, VisualHg (http://visualhg.codeplex.com/) that seems on par with VisualSVN.  It's being used by the StackOverflow team too.
September 8, 2010 11:28 AM
 

JonRobertson said:

VSS was the first version control system I ever used.  And it didn't take me long to loath it.  We had to make regular backups because the VSS database would corrupt itself frequently.  :(

I had some exposure to CVS ad PVCS while we were still using VSS and didn't see anything that excited me.  Then, in 2002, I saw a demo of StarTeam at a conference and was hooked.  A year later, we purchased StarTeam and made the big switch.

I'm disappointed that more systems don't offer "change management".  You can see check-in comments for individual check-ins, but you don't see a "big picture".  For any particular enhancement or defect, what changes were made to the code?  How many files or which files were updated?  How long did the enhancement/fix take from start to finish?  This is the #1 feature that StarTeam brings that we can't live without, now that we've used it for 7 years.

Unfortunately, the price tag is quite high.  But once you've made the investment, it pays for itself.  It works extremely well for disconnected, distributed developers.  Check-ins and check-outs are very fast, even for remote developers.  It has a solid branching and merging system.  And it integrates well into any IDE that supports MSSCCI.
September 8, 2010 11:39 AM
 

mbutenko said:

I have used VSS and SVN and dabbled in TFS Basic with VS2010.

I had reasonable success with VSS when using it with small development teams working closely with one another (i.e., what it was intended for).  I never had the corruption issues that I've heard others speak of.  

Most of my work is now with SVN and using AnkhSVN as the VS integration client.  I like it just fine but when using it strictly for source control on a small team, I don't see a significant gain over VSS.  

I like the promise of the ALM (Application Lifecycle Management) functions all in one provided by TFS.  However, lately I've been too busy to learn and explore how to use them all, along with VS2010.  If I can learn it all and get it all to work properly, I think that would be the holy grail.
September 8, 2010 3:36 PM
 

IowaWebDave said:

VSS just plain worked for us with Visual InterDev and Classic ASP.  Team Systems in Visual Studio, on the other hand, caused us plenty-o-headaches.  Why in the world would it not allow someone to be in both the developer and admin group?  (If you are, you only get the lowest-level permissions - effectively removing your admin privileges!)

As Tony said, integration within the IDE is paramount and since we're a MS shop, we're stuck with what they give us.

Here's hopin that they really did improve TFS! ;-D
September 8, 2010 3:37 PM
 

sunporch.james said:

We have decided to go from Seapine Software's SSCM to git.
Reasons: simplicity, free, distributed.
We are a 2 person team, one at HQ in USA, one in Buenos Aires, AR
Merging and branching are not used now, and we want to use them without the headaches.
We are a microsoft visual studio.net and SQL server shop.
We use Red-Gate SQL Compare to manage db versions, and so are bypassing source control for our database scripts - if/when we grow to a bigger team, we would likely look into this - and likely look into the Red-Gate solution.
Regarding integration with the Visual Studio .NET IDE - I could care less at this point, since I envision git's simplicity/usage model to be make the right-click checkout/checkin cycle mostly irrelevant.
Cheers -james
September 8, 2010 4:17 PM
 

sunporch.james said:

PS: We were a VSS shop for years before using Seapine, and never had any corruption problems, and we used SourceOffSite for some time - but as projects grew in size, using SOS over the internet was too slow.
-james
September 8, 2010 4:20 PM
 

timothyawiseman@gmail.com said:

It seems popular to bash VSS lately, and to a degree I understand that.  It is indeed outdated compared to more modern systems.  With that said, it has one major advantage that few other systems match.  It is highly intuitive and easy to use.  We have several non-programmers that use it without any problem after only minimal instruction, and most programmers I have worked with just use it without ever being taught or resorting to a manual.  Even configuration and administration is easy in all but the most complicated of scenarios.

In comparison, we recently migrated to SVN here.  I am quite fond of its power and flexibility, but even with additional GUIs it is difficult to learn and not at all intutive.  Our nonprogrammers have a great deal of problem with it.

At home, I tend to use Mercurial (Hg) and I have been tremendously happy with it.
September 8, 2010 5:15 PM
 

alekdavis said:

We have used PVCS (in the late 90's), StarTeam (for about 7 years in early/mid-2000s), VSS (for the whole 2000 decade), TFS (from around 2007 till now), and Subversion (started early this year). All for enterprise projects and multi-national teams (most projects are quite big). PVCS sucked. StarTeam was quite good (although we did not use VS IDE integration at the time). VSS was OK. I think we may have had a case or two of minor file corruptions, but the major problem was performance for overseas team (they used a commercial plugin to make it work). TFS had a bumpy start. We spent several months changing projects to make them TFS ready (the major problem was the fact that TFS did not support file sharing between projects and we had lots of shared source -- C/C++ -- files). Other than that, TFS was OK. We do not use any features other than source control. We use Subversion for Java projects. It's OK, but between TFS and Subversion, I prefer TFS (we would've used TFS if we found a plugin for JDeveloper).
September 8, 2010 5:59 PM
You need to sign in to comment on this blog
<September 2010>
SuMoTuWeThFrSa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
Automated Script-generation with Powershell and SMO
 In the first of a series of articles on automating the process of building, modifying and copying SQL... Read more...

Converting String Data to XML and XML to String Data
 We all appreciate that, in general, XML documents or fragments are held in strings as text markup. In... Read more...

Geek of the Week: Don Syme
 With the arrival of F# 3.0 Microsoft announced a wide range of improvements such as type providers that... Read more...

How to Document and Configure SQL Server Instance Settings
 Occasionally, when you install identical databases on two different SQL Server instances, they will... Read more...

What's the Point of Using VARCHAR(n) Anymore?
 The arrival of the (MAX) data types in SQL Server 2005 were one of the most popular feature for the... Read more...