SVN vs VSS vs CVS Comparing HELP
Asked Answered
T

7

5

We are currently determining if we would move CVS and VSS projects to a single SVN server.

I've been using SVN for a long time now but is forced to use CVS and VSS for work stuff.

Would you please help me give reasons why moving to SVN would be better than buying a VSS 2005? And also what the benefits of moving from CVS to SVN would be?

We have projects in C#.NET/Java/Perl/Visual Basic.

Beyond the cost difference what more can i say to the bosses to convince them to move to svn.

And is there a way to preserve the histories of the VSS and CVS when moving to SVN?

Tourbillion answered 9/7, 2009 at 3:29 Comment(1)
Possible duplicate: #18024Devastation
M
4

SVN versus CVS is simple. SVN was developed as a new Software to be used instead of CVS to correct some issues with CVS.

One issue I know is the problem with moving and renaming files inside the repository. This is a big issue if you tend to refactor a lot in your codebase.

More is found here: Limitations of CVS on Wikipedia.
And here: Criticism on VSS on Wikipedia
And for comparisons: Limitations of SVN on Wikipedia

Melody answered 9/7, 2009 at 3:36 Comment(0)
I
10

This is one of those questions that requires a lot of details, but it will boil down to "Why do you like using SVN?" and what you can use from the "like" list to present to your boss.

I've used all three. I can only speak for my own experiences and bias. My usage history is VSS --> CVS --> SVN

CVS

Pros:

  • It can be used across the internet
  • Very stable

Cons:

  • It is very hard to rename things. This causes a lot of pain.

My main beef with it was client software. I found all of the client software incoherent and disjointed. I absolutely hated using it.

VSS

Pros:

  • Sharing projects is dead easy.
  • Integrates well with Microsoft IDEs

Cons:

  • It uses the Microsoft Jet storage engine, which is prone to corrupt whatever it is accessing.
  • It can't be used outside of your LAN, unless you buy something like SourceOffsite.
  • The checkout-lock files and checkin-unlock files can slow down productivity in larger groups. A lot of newbie developers leave files checked out, and the rest of the team has to wait on them to make any check in.
  • Microsoft does not develop this anymore. Microsoft doesn't even use this internally for their cash cow apps like Office and Windows. They actually use a custom version of Perforce.

Subversion

Pros:

  • Checkout-edit-merge file editing cycle is very team friendly
  • Creating branches is very cheap and doesn't copy physical files
  • It's being continually developed
  • There are several Subversion packages to choose from
  • A lot of third party vendors integrate with Subversion. It has a rich application ecology.
  • One major advantage is that you can now integrate security Subversion with your Active Directory tree.

Cons:

  • Merging conflicting can still be a major pain in the neck, but this is the same as with most other version control systems.
  • Security can be a bit tricky to use depending on which server (svnserve.exe or Apache/WebDAV) you choose to run your repositories.

I'm guessing that since your bosses want to buy VSS2005, that this will be running on Windows. My recommendation is that you stick with one of these 3 Subversion distros/packages

General Subversion installation package: CollabNet Subersion - http://www.open.collab.net/downloads/subversion/ This will install both svnserver.exe (custom server) and Apache/WebDAV or you can choose which one to install during setup. You'll be able to serve your repositories using both http:// and svn:// protocols.

Subversion plus Administration console: VisualSVN Server - http://visualsvn.com/server/ They do their own Subversion distribution. This package has a Microsoft Management Console (MMC) snapin to manage the server. This one will help you setup permission against you Active Directory tree. This is mainly geared towards http:// protocol.

Subversion Administration console: PainlessSVN - http://www.painlesssvn.com This one will only work with svnserve.exe (custom server). It's a Microsoft Management Console (MMC) snapin that will manage the settings, and users. This is mainly geared towards the svn:// protocol.

Tom Ritter gave some very good links to tools that will import history and code from CVS/VSS to Subversion.

Inchoate answered 9/7, 2009 at 4:34 Comment(1)
One CVS client I liked allot was CrossVC.Alewife
M
4

There are tools to convert CVS history to SVN and other tools to migrate VSS history - so you can use them in your case of moving to a better system.

For all the reasons linked in the comment and elsewhere, SVN tends to be a much better enviroment than CVS or VSS (unless you have some weird requirements) - so if you can successfully import your history and save the company money, I wouldn't see why the bosses wouldn't go for it.

Minni answered 9/7, 2009 at 3:35 Comment(0)
M
4

SVN versus CVS is simple. SVN was developed as a new Software to be used instead of CVS to correct some issues with CVS.

One issue I know is the problem with moving and renaming files inside the repository. This is a big issue if you tend to refactor a lot in your codebase.

More is found here: Limitations of CVS on Wikipedia.
And here: Criticism on VSS on Wikipedia
And for comparisons: Limitations of SVN on Wikipedia

Melody answered 9/7, 2009 at 3:36 Comment(0)
A
1

You can definitely preserve the history moving from VSS to Vault, which wasn't on your list, but which I highly recommend. If other developers are used to VSS, they'll have absolutely no problems getting used to Vault. It's not free, but it's a lot cheaper than a lot of the alternatives.

As far as convincing them to move, VSS really should've provided its own reasons by now. I was constantly amazed our VSS repository never crashed, but then I never knew another developer was repairing it almost daily.

Anking answered 9/7, 2009 at 3:36 Comment(2)
Luckily I haven't used VSS for years, so I've still got a bit of hair on my head. But when I was ... arrgh, even the VSS Analyze tool didn't fix some quirky issues in the database. Occasionally we'd move the current repository as a backup, and snapshot the current code into a new one to avoid the bugs.Frons
SourceGear Vault and Fortress are free for a one person license.Barnard
E
1

Others have mentioned why SVN is the best in your line up. Also you should be aware there are newer and better version controls systems out there than SVN.

Two great ones are Mercurial and Git.

Exhale answered 27/5, 2011 at 0:4 Comment(0)
T
0

There are many reasons to upgrade to SVN from CVS. We used CVS as our source control from 2002 through 2007. I will say during that time we never had one issue with CVS. The real problem is that CVS hasn't moved forward since about 1998 in terms of feature development.

The biggest benefit of SVN over CVS has to be true autonomous commits. We used the open source tool cvs2svn to pull over all our CVS projects to SVN. We didn't have a single problem and kept full history on everything.

VSS: This truly has to be one of the worst Microsoft products ever created. File corruption, history loss and major problems with merging are the major reasons to stay away. At this point I am pretty sure Microsoft is deprecating VSS in favor of the Team Tools built into Visual Studio Team Edition.

Thitherto answered 9/7, 2009 at 4:24 Comment(0)
F
0

Two of my favourite things about SVN:

  • The way branches are made is nice and simple. I never could get my head totally around CVS branching.

  • Hidden local copies mean that commands like "svn diff" and "svn log" don't have to contact the server. This makes working with a checked-out repository on an unconnected laptop far easier.

Footie answered 9/7, 2009 at 4:32 Comment(1)
If you like those then you should really, really, try Git. Real branching support and a full local history might just blow your mind.Cobham

© 2022 - 2024 — McMap. All rights reserved.