问题
I tend to get the feeling that most folks here think SVN is gold-plated goodness, whereas VSS is the worst program ever devised (at least as Version Control is concerned).
That said, why? I've used some CVS, and my current job uses VSS, and from a grunt on the team's perspective, I can't really tell that much difference. Most of the differences I've seen are cosmetic. Granted, I've not tried to do any branching/merging in either, but as a coder who comes in, checks out files, works on those files and checks them in at the end of the day, why would I want 1 over the other?
回答1:
“Visual SourceSafe? It would be safer to print out all your code, run it through a shredder, and set it on fire.” - (Attributed to an unidentified Microsoft employee).
SourceSafe has many problems and no redeeming features. There are several freely available, cross-platform alternatives that are safer, faster and more powerful. Subversion is probably the most widely used of these. Some people prefer distributed version control systems such as Git, Mercurial or Bazaar.
Some reading about why VSS is so bad:
- Visual SourceSafe: Microsoft's Source Destruction System
- Visual SourceSafe Version Control: Unsafe at any Speed?
- (And my own experiences)
回答2:
Microsoft, which makes Visual Source Safe, does not use it internally for any projects of any significant size. That's a major mark against it, in my book. And using it for large projects, you understand why; it's SLOW, and god help you if you ever decide to let it auto-merge anything.
回答3:
VSS is not atomic, so a get latest during a large check-in from another user will result in an incomplete file set. This also gets worse if working over a WAN due to the design of VSS to work over shares.
回答4:
My last-but-one company switched from VSS to SVN because of
- Expansion. The number of programmers doubled and we didn't want to fork out for the extra VSS licenses
- Bugs. VSS is good at maintaining the latest version of a file, but histories often got corrupted.
- More bugs. The checking/recovery tools were useless as they started crashing when the database got very large.
回答5:
I know that it is easy to pick on VSS, but it is important to remember a few things (get out of the weeds for a second!)
- For small Microsoft development teams, VSS is a very easy to implement solution, where the alternative is NO VERSION CONTROL.
- VSS has no cost, requires no server (other than a file share).
- Lowest common demoninator.
- It generally does work, and a number of shops use it.
- I would rather have VSS as an option than for it to not exist.
You don't have to agree with me on all these points, I'm only demonstrating that it does have it's place, and has value in different scenarios.
回答6:
SVN has some important features over CVS/VSS, like atomic commits, cheap copies, more efficient storage on the server side.
SVN is, however, not the only revison control system out there... There are a lot of different revision control applications. A new trend seems to be towards distributed revision control, like Git or Mercurial.
回答7:
VSS has a really bad history that it has to overcome. More recent versions seem to be more stable, but it still has a metric crap ton of negative baggage that it is toting around.
回答8:
The old argument of integration in Visual Studio doesn't work any more. AnkhSVN 2.0 delivers an integrated solution and VisualSVN integrates TortoiseSVN into Visual Studio.
And TortoiseSVN itself is enough reason to switch for many users.
回答9:
I have problems with VSS with Java code. While a getLatestVersion, VSS is unable to handle the nested structure of projects and packages in java. I got inifite folder structures for the same. SVN is quite simple in this regard.
回答10:
You should run from VSS as soon as you can. If you haven't had problems with it in the past then you are due from some. It's like a Russian Roulette time-bomb - you never know when it's going to blow.
SVN is a great tool and very easy to setup, manage. Administration tools for backing up or replicating are very nice.
I would recommend SVN over VSS anyday.
回答11:
Well CVS and VSS are pretty much the same thing as far as functionality goes. So they are not a good starting point to compare each of them.
However you probably will never see a difference between SVN and VSS if you just use them as a grunt on the team. You really have to start using them as a project manager to really see the differences, such as branching, merging, etc.
回答12:
SVN works well from a developer standpoint, but the way it stores config info all over the directory tree is maddening to sysadmins (especially those tasked with moving it to another server when the developers refuse to do a commit/re-checkout process). :) So, it's not ALL gold-plated goodness!
回答13:
I actually think Perforce is the gold-plated goodness. The GUI tools are good enough that you can give them to a designer or artist and get them to use source control like us devs. I'm pretty sure the VSS File->Add Files window predates windows 95. The whole concept of files in use being locked is absurd. Didn't we solve that decades ago with CONCURRENT versioning? I have experienced history corruption and (correct me if I'm wrong) but VSS does not even support branches and merges.
来源：https://stackoverflow.com/questions/306339/svn-vss-why-is-one-better-than-the-other