views:

1652

answers:

16

At work, one of the head managers asked me to research on what could be the benefits of changing the current source control server (Visual Source Safe) of my project to SVN.

I really don't have anything against SVN, actually I kind of dig it, but in my humble opinion, change to SVN will not bring any significant benefits to the project, and will force us to use some third-party tools to manage the source control from the Visual Studio (we develop using mostly Microsoft tools only).

So, as a first step in my research, I ask you: what could be the benefits of switching from VSS to SVN?

+31  A: 

SVN is more popular than VSS and has lot's of advantages. VSS is old and outdated.

Many developers nowdays are moving from VSS to SVN. If you will search for "SVN" and "VSS" in Google, it will show you lots of articles related to VSS to SVN migration.

  • VSS's lock-modify-unlock model makes collaboration on rapidly-changing files a major headache. Plus the overhead of needing an admin to unlock files that someone has checked out while they're on vacation.
  • With VSS, it's not a question of if you'll lose data - it's WHEN. Your source repository is supposed to be a rock - if a developer's workstation crashes, you should only have lost HIS changes. You shouldn't lose random files and data from the repository
  • VSS hasn't been maintained by MS in over 6 years. Can you even get support for it anymore?
  • Depending on your backup tools, you may not be able to get a complete backup of your VSS repository if you have just one person left logged into the server (meaning they left their dev tools open, or left the VSS client running).
  • VSS requires that all users have nearly full control, at the filesystem level (NTFS permissions), of the files that make up the repository.
  • There is no good, usable, easily available published API for VSS and 3rd-party tools are weak for the most part.
  • Merging sucks in VSS.
  • VSS: If you have developers spread across multiple timezones, the very act of both of them checking in can corrupt the database if they check in too close together, in the wrong order.

Now, this isn't to say that Subversion is faultless - there are certainly things it could do better, and things it doesn't do at all. But all the people who worked with VSS and SVN most likely will never come back to VSS.


If you will choose SVN. Here is a list of tools you may need:

  • AnkhSVN is a Subversion SourceControl Provider for Visual Studio.
  • RapidSVN is a cross-platform Subversion client.
  • TortoiseSVN is an easy to use SCM / source control software for Microsoft Windows and maybe the best standalone Subversion client there is.
  • VisualSVN is a Visual Studio plug-in that integrates Subversion and TortoiseSVN seamlessly with Visual Studio.
  • VisualSVN Server is a package that contains everything you need to install, configure and manage Subversion server for your team on Windows platform. It includes Subversion, Apache and a management console.


Here is a great book on this subject: Version Control with Subversion by C Pilato

Version Control with Subversion


Another good alternative to VSS and SVN is SourceGear Fortress which has Issue Tracking system in addition to source control - all in one. Or SourceGear Vault - source control only. Also there is SourceAnyWhere solution. If you need Microsoft solution than go with TFS instead of VSS.

Koistya Navin
P.S. I personally preffer Fortress Source Control server for small projects which has issue tracking functionality in addition to Source Control.
Koistya Navin
wow! what an answers man! thanks a LOT! =D
Hugo
I would like to comment that VisualSvn is NOT worth the money they charge - I did not thinking of dumping my post in total but here is a link with some more info (also posted below): http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/
Tab
The CodePlex.com comment is confusing. Internally, Codeplex runs on Microsoft's Team Foundation Server (TFS), which is a proper Source Control server. They offer a Bridge to SVN on top of it because SVN is so hugely popular in the Open Source world, but that bridge still has quirks. But VSS is indeed not supported by CodePlex at all.
Michael Stum
Re VisualSVN -- I couldn't disagree more. The first time you start moving and renaming files en masse it will pay for itself. I can't believe how long I went without it.Visual SVN server takes all the pain out of setting up an HTTPS server too. And it's free.
JohnOpincar
+1 for Visual SVN. We migrated 3 projects from VSS to SVN, and started using VisualSVN right away. Seamless, painless, worth it.
callisto
+3  A: 

Avoiding the headaches of a Source Safe database crash taking your whole codebase with it is a biggy.

Not having to worry about who has a file checked out is another.

Moose
Who has a file checked out...man that's one of the things that I hate the most...thanks for your comments! =)
Hugo
+2  A: 

I find merging files with VSS to be very cumbersome, but it's great with SVN. Also, and I don't have any evidence of this, but SVN seems faster.

Matt Grande
Agreed - File merges with VSS are basically a manual chore. I haven't had problems with stability or speed though.
JosephStyons
In VSS defense, the heavier locking model means merging is relatively rare.
Joel Coehoorn
It also means that when you co-worker goes on vacation for a week without checking in some files, you can't get at them.
Matt Grande
haha Matt, I've been there...thanks for your comments =)
Hugo
+2  A: 

VSS is old and outdated. The database gets corrupted way too often. There's a reason why MS built TFS too.

SVN is very popular (meaning lots of community support, meaning free support), there are many tools that hook to it (CruiseControl for Continuous Integration for example) and it's rather simple to use.

You have to consider there's a learning curve if you are already using VSS and that's something that you have to weigh in your research. If the other developers haven't used SVN (or CVS) then it could be costly, although all you need is one person who really gets to know the system and then coach the rest.

We did change from VSS to SVN 4 years ago and we haven't looked back since.

Rezlaj
The learning curve wouldn't be that much of a trouble, my teammates and I already have work with it (at least on a basic way). Thanks Rezlaj =)
Hugo
We made the change in 1 day, as a team of 3 devs + 1 pm.
callisto
+1  A: 

SourceGear Vault is an excellent replacement for VSS. It started out being "VSS features but using a real database", and grew from there.

John Saunders
+2  A: 

Just as an aside, we've been using Sourcegear Vault for a number of years quite happily. Having repositories and a central SQL Server database along with great access over the internets made it a slam dunk for our organization.

I think it's reasonably priced and at least worth a look.

billb
Thanks man, I'll take a look at Sourcegear Vault =)
Hugo
+1  A: 

Almost Definitely SVN. SVN sports a different way of working (Copy-Modify-Merge instead of Lock-Modify-Unlock). It's a bit of a learning curve, but it's the way things have gone for several years now, so most devs will have to learn it at some time or other anyway. Lock-Modify-Unlock is way too much of a pain, and there are serious collaboration problems that it actually contributes to, which I'd be happy to explain if you're curious.

Seconding the comments about how bad VSS is as well. Here are various links that cover the topic:

http://www.codinghorror.com/blog/archives/000660.html

http://www.developsense.com/testing/VSSDefects.html

http://wadhome.org/svn_vs_vss.html

Edit: See also: http://stackoverflow.com/questions/283221/source-control-lock-vs-merge#283236

This is interesting: If VSS is lock-modify-unlock, and SVN is copy-modify-merge, then DVCS' (git, hg, etc) sound similar as branch-modify-merge. The merge step is quite different between the two, however.
thenduks
Thanks for your comments, I'm checking the links already =)
Hugo
+13  A: 

Microsoft has admitted to never using VSS on any of their internal projects (can't find the reference right now though :/). I used it for two years and it was stupid bad. Database was corrupted at least once a week.

Also, one of my favorite things to quote to VSS users is the first quote on Eric Wadworth's page, reportedly from someone at Microsoft:

"Visual SourceSafe?  It would be safer to print out all your code,
run it through a shredder, and set it on fire."

Definitely go with SVN. VSS is like the nightmares of 1000 demons.

womp
Hey! thanks for your comments! =)
Hugo
+1 for use of the term "stupid bad"
qntmfred
+2  A: 

AnkhSVN 2.0 is really very good.

If you had Visual Studio integration as a requirement, I would have warned against SVN even a year ago, but that's changed in a big way. It's still not as good as, say, VS Team System, but it's much better than the old MSSCCI-based VSS integration. There's no reason not to use SVN with .NET.

Darcy Casselman
+2  A: 

Another "definitely SVN" vote here. I was part of a migration team at a previous job. I can't tell you how nice it was to get rid of VSS.

  • No more corrupt repositories
  • Much better merging
  • So much faster
  • Cheap and easy branching
  • No more exclusive locking
  • Checkout the source to multiple locations really easily

I could go on, but the memories of the VSS shackles are too painful. Just say no.

Jon Skeet
haha sorry to bring back the pain! XD Thanks for your comments =)
Hugo
+10  A: 

Consider a more modern tool like Git, Mercurial or Darcs. There are plenty of advantages, I'll leave the googling as an exercise to the reader.

thenduks
I have consider to move to Git also but, as the project is rolling and the learning curve would be near inexistent with SVN. Thanks for your comments =)
Hugo
It's pretty trivial to simply use git exactly as you'd use SVN initially. Check out http://gitready.com/. Good luck with your project.
thenduks
I love git and would recommend it for any new project. But if you go with SVN, keep in mind that git-svn allows you to use both git and SVn together. So, you can get the best of both worlds.
Clint Miller
+4  A: 

We use SVN where I work and with the right documentation, right client and tools it is a snap - so far it is highly reliable to work with. After having spent the past 10 years with VSS I can say I don't miss it a bit.

I like SVN so much I wrote a review of what I consider to be the most valuable clients (some are not) and additional tools. This is a new article so it is very timely: http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/

I would not hesitate to recommend SVN to anyone - GIT is next on my list to look at.. Hope this is helpful.

Tab
Thanks for your comments! =)
Hugo
+1  A: 

Speaking as someone who went through the VSS -> SVN transition process for a large codebase, I would say the biggest benefit is being able to sleep soundly knowing that your SCM system wont suddenly have a hiccup that corrupts your database and you have to go back to yesterday's backup. You do backup your database daily, right?

With VSS, corruption happened at least once per month. With SVN (same hardware & OS) - not once in over two years.

Oh, and the branching/merging capabilities are sweet!

Ferruccio
Thanks for your comments =)
Hugo
A: 

Just an addition to Koista Navin's answer.

He said: Here is a great book on this subject: Version Control with Subversion by C Pilato

There is a free online version:

http://svnbook.red-bean.com/

alkaloid
Great alkaloid! Thanks man =)
Hugo
A: 

Definitely, go with SVN, for all stated reasons above. You could try it ankhsvn which is a svn plugin for visual studio. This way you get the best of both worlds: using SVN and all work still gets done inside visual studio.

JLP
I've been using the lastest version of the AnkSVN and I should say it works like a charm.Combining Tortoise and AnkSVN has been the winning combo
Hugo
Cool! Glad I could help ;)
JLP
A: 

Team Foundation Server is the optimal choice for developing in the .NET world. However it is not free and for the current version 2008 it can be quite expensive. If you have higher level package for Visual Studio you do get TFS workgroup edition for free which allows 5 users access for no additional cost.

There are some major caveats to the workgroup edition you must use one of the 5 slots for the TFS service account unless you set it up to run under a users account that will be included in the TFS member list. The other is once you hit your 5 user limit the jump to 6 users is a fairly staggering cost as the current license requirements include the need to purchase the server (a few thousand dollars) AND CALs for every member of the team. That's a fairly prohibitive cost to add one more member to the team.

However, Microsoft has come to realize this and is changing this for 2010. You will no longer need to purchase the server itself and will only need to purchase CALs. TFS 2010 server licensing: It's included in MSDN subscriptions

Chris Marisic