问题
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?
回答1:
SVN is more popular than VSS and has lot's of advantages. VSS is old and outdated.
- Why Not VSS
- Visual SourceSafe: Microsoft's Source Destruction System
- Source Control: Anything But SourceSafe
- Visual SourceSafe Version Control: Unsafe at any Speed?
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 http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
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.
回答2:
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.
回答3:
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.
回答4:
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.
回答5:
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.
回答6:
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.
回答7:
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.
回答8:
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.
回答9:
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.
回答10:
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.
回答11:
SourceGear Vault is an excellent replacement for VSS. It started out being "VSS features but using a real database", and grew from there.
回答12:
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: Source Control - Lock vs. Merge?
回答13:
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!
回答14:
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.
回答15:
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/
回答16:
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
来源：https://stackoverflow.com/questions/690766/vss-or-svn-for-a-net-project