--On Friday, December 08, 2006 9:53 AM -0700 Nathan Palmer
<[EMAIL PROTECTED]> wrote:
I noticed on your blog that mentioned a write-up comparing VSS,
Subversion and SourceGear Vault. Is that anywhere public? I'm currently
compiling a comparison myself because we need to move away from our 10
gig VSS database ASAP. But I need to make sure that we would be doing
the right thing by converting to Subversion. I'm curious to see what you
wrote about it.
These are the notes I worked from when doing the same:
Subversion benefits over Visual Source Safe (VSS):
Database integrity
The Subversion developers place their highest emphasis on protecting
data. VSS databases have a reputation for frequent corruption.
Security
Subversion is easy to deploy over an encrypted link. One can use
svnserve over a secure shell (ssh) link, or the Apache Subversion
module over Apache's SSL (HTTPS) protocol. This eliminates the need to
use special VPN software to secure communication with the repository.
Different parts of a repository can have different access policies.
Multiple repositories can be served from a single Apache web server.
For example, one could restrict commit rights to the main trunk to a
small group of project leaders, while allowing each developer or team
a separate branch to work within. Project leaders would review
easily-identified changes in a team's branch and commit them to the
trunk. This is in fact how Subversion itself is managed, ensuring high
quality in an open source environment with many independent
contributors.
Performance over WAN
VSS was designed for a LAN, and requires massive disk activity for
even simple operations. Subversion was designed for global clients. It
strives to minimize network traffic. Many common operations can be
performed without connection to the repository, such as comparing
one's working copy to the version that was checked out.
True client/server
VSS is a peer-to-peer system in which every client is really a server,
requiring full access to the underlying database. Faults in any peer
can damage the database, and this is known to happen frequently.
Subversion is normally deployed as a client/server architecture, with
a single server having access to the actual database. If a fault
happens in a client during a transaction, the server will roll back
the transaction, protecting all other clients from corruption.
Cheap copies (ie. branches and tags)
One can copy large parts of a repository to another path, and only the
fact of the copy is stored, not the actual data. This makes it very
cheap (almost free) to tag and branch. This in turn makes it cheap for
developers to create private version-controlled "sandboxes" where
large features can be developed without the need to coordinate with
other groups. Only once the entire feature is tested is it merged into
the trunk. The developer can merge well-tested trunk developments into
her branch.
No downtime for "maintenance"
Normal maintenance is just backup. This is done with an administrative
command ("svnadmin dump") that performs a normal database lock, so the
repository remains highly-available.
Disconnected development
One doesn't have to be connected to the repository to start work, as
long as one has a working copy. If you're on a plane or waiting for
your train to the office, you can power up your laptop and immediately
start editing. No need to lock files before you begin. Subversion
makes this particularly easy because your working copy contains a
pristine copy of the original checked-out files, before you started
making changes. (This copy is normally kept in the .svn subdirectory
under each working directory.) This makes it easy to monitor your own
edits without using the network.
Subversion developers "eat their own dog food"
Microsoft does not use VSS internally. It's not an actively-maintained
product.
The Subversion developers use Subversion to manage the development of
Subversion. It's in their own interest to make it the best system it
can be.
Support:
Documentation is extremely good.
The Subversion developers are readily available through user and
developer mailing lists.
More information:
Subversion feature list: http://subversion.tigris.org/
Subversion Frequently Asked Questions: http://subversion.tigris.org/faq.html
Extensive testimony on the dangers of VSS:
http://web.archive.org/web/20050205021025/www.wadhome.org/svn_vs_vss.txt
Microsoft's Source Destruction System:
http://www.highprogrammer.com/alan/windev/sourcesafe.html
VSS: Unsafe at Any Speed:
http://www.michaelbolton.net/testing/VSSDefects.html
Wikipedia on eating one's own dog food:
http://en.wikipedia.org/wiki/Eat_one's_own_dog_food
VSS security: http://lists.virus.org/bugtraq-0212/msg00294.html
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
