Geek Answers Handbook

Source Control Toolkit Industry Reports

I am looking for independent industry reports that compare and compare various version control tools there. In particular, I care about Clearcase vs Sourcesafe vs SVN, but if the report includes other SCM systems that are fine.

I need this for a client who wants to understand what exactly they want to get by switching to SVN (yes, from Clearcase and VSS). In other words, I can use something to sell it to my business.

I hope that some case studies were conducted on the productivity of developers using these tools, and the reports received were freely available.

Thanks Kent

+4
source share
4 answers

I was looking for something like this when I first started working in a company that did not have version control (yikes). The development person at that time mostly looked at Microsoft stuff, and the only other person in the small development team with SCC experience was using SourceSafe only.

I had a lot of experience with SVN, so admittedly I'm pretty biased, but I really tried to make an assessment of SVN vs VSS vs TFS. I really could not find something positive in VSS, except for people who compared it to the fact that they did not use the control source at all.

Sourcesafe

  • Visual SourceSafe: Microsoft Source Destruction System

    • From the article:
      • SourceSafe does not have useful branching support [..] Merge support SourceSafe is tightly integrated with validation, making it difficult to examine the differences and validate the proposed merge before validating it on a tree. With such a weak level of support, it is easy to check for broken code in the version control system.
      • When updating the local workspace in accordance with the server, files that were deleted on the server should be brought to your attention. (Or removed, because the old version can be obtained from the version control system.) Failure to do this means that your project uses outdated files, which often causes problems. [..] SourceSafe does not delete the obsolete file or does not give any warnings.
      • SourceSafe's original design assumes that customers are trustworthy, always working correctly, and that nothing interferes with data exchange, causing corrupted data. As a result, SourceSafe is fragile and unreliable. I worked with SourceSafe in three different workstations. In each case, the SourceSafe database was corrupted. Data was damaged, work was lost, time was wasted on the problem.

  • Visual SourceSafe version control: unsafe at any speed?

    • From the article:
      • SourceSafe seems to work reasonably when you use a simple creation cycle, and then develop the source files, check the files in the given floors, mark the project, etc. However, many simple actions lead to software failure in various subtle (and sometimes unreasonable) ways. "The deleted file can be easily deleted from the database, preventing the rebuild of previous versions of the project. ''
      • The user can reasonably expect the Destroy command to delete the current working version of the file from the user's hard drive. The user can also reasonably expect the Destroy command to delete the file from the current version of the project. The user may not expect the file to be deleted from all previous versions of the project.

  • CodingHorror: Source Control: Anything, but SourceSafe

    • From the article:
      • SourceSafe was an adequate version control system in the late 90s. Unfortunately, SourceSafe has never been updated architecturally to reflect modern version control methods. Even the latest version, SourceSafe 2005, absolutely smells in 1999.
      • SourceSafe gives you the illusion of security and control, putting your project at risk.
      • SourceSafe teaches developers bad habits: avoid branching, exclusive locks, simple persistent deletions.

  • http://www.wadhome.org/svn_vs_vss.html

  • From http://svn.haxx.se/users/archive-2006-11/0242.shtml :

    • VSS uses file locking by default. If the user checks (blocks) the file, then leaves the company or goes on vacation for 2 weeks, the administrator must manually unlock the file if someone else needs to work on it, and when this other person returns, you have a merger in your hands. Merging is not very good from what I remember.

Short VSS vs SVN (taken from http://better-scm.berlios.de/comparison/comparison.html ):

  • VSS is not atomic - if the network goes down, the power is turned off (on the server OR client), etc., the repository is damaged. SVN is atomic, or all changes fall, or none of them performs
  • VSS blocks files - several people cannot work in one file at a time.
  • VSS changes are file dependent. SVN can commit changes to multiple files as a single “set of changes."
  • VSS does not track line changes. With SVN, you can see who last changed the line and in which revision ("blame svn")

Subversion

A very simple source code management system. Changes tracks, uses the update-merge-commit model, which allows several developers to work on the same file at the same time, and subversion automatically merges its changes (when possible). No “magic” happens.

Integration with Windows / Explorer through TortoiseSVN . Integration with Visual Studio through VisualSVN ($ 50 / developer) is really just a TortoiseSVN interface.

Integrates with many third-party tools, for example:

Svn Cons:

  • There is no built-in merge tracking (tracking what changes have been merged, for example, from development to a stable branch)
    • Maybe with svnmerge / svnmergegui
    • SVN 1.5 has built-in merge tracking
  • Missing shelf function
    • Allows someone to work on something and “put it off” in the repository (without making it part of the project), where other developers can pick it up.
    • TFS has this
    • It can approximate this function using patches or by creating a separate branch.

Team Foundation Server (Visual Studio Team System Team)

Uses the SQL server as a backend (therefore, it is reliable). It has a built-in toolkit for error tracking, project planning, continuous integration.

My super-quick summary:

  • VSS sucks
  • TFS seems very useful / capable, but quite expensive as soon as your team grows to 5 people.
  • SVN is useful and well tested and has no cost

What has become possible for us is that the possible benefits of TFS were not worth the huge additional cost.

What is it worth, now a couple of years since I wrote it. The guy who was previously responsible no longer works with the company, I am now a development manager, and our team is 3 times bigger. We use a combination of SVN, VisualSVN + TortoiseSVN and Trac. I do not think that any of the developers could no longer use these tools. Everyone managed to build SVN very quickly, perhaps with the exception of merging branches, which some of them are still not sure about doing on their own.

Jeff Atwood (creator of stackoverflow) discusses SVN a bit in one of his Joel podcasts: http://blog.stackoverflow.com/2008/06/podcast-10/

+14
source

There are many places to compare with each other, but they are almost always biased towards one system.

Here are some comparisons that I have used in the past.
better-scm
Dynamic comparison site
wikipedia

The Wikipedia site is actually quite detailed and easy to read.

+3
source

Forrester Research publishes a report every few years. The 2007 version is quoted by IBM and CollabNet , the people behind Subversion .

+1
source

we use SVN at my work for about a year (dictated to the maximum). All I can say is if you want to do a merge, stay away from SVN with a long pole. Jokes aside. It's unhealthy. To control the underlying source, this is normal. With merging, this becomes a nightmare. And don’t tell me that we are using it incorrectly. We have all tried. It is simply not designed to work properly for a merger. But if you decide to do this, I wish you good luck than ours.

+1
source

More articles:


All Articles