[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion vs CVS whitepaper/analysis

From: Nathan Yospe <nyospe_at_gmail.com>
Date: 2007-01-11 06:26:35 CET

I am a senior developer with a medium software development team (for
the last two years, part of a very large software company... second
largest in the world, now, even if #3 denies it) in Los Angeles, and
have been in charge of source control since '02, when I migrated our
development from SourceSafe to CVS. Since that time, our company was
acquired by the aforementioned giant, which uses Perforce, and our
team grew from a dozen developers to well over thirty.
A year ago, I came to the realization that CVS was not going to be
able to keep up with the overhead of branching and tagging, along with
the demands of automated test and merge processes, and began looking
into switching to one of the two systems I had considered four years
earlier. At that time, Subversion was not yet mature enough, and
Perforce too expensive. Now, I was faced with beaurocratic problems
with Perforce... and some disturbing test results for branch and tag
When I tried Subversion, this time, the most impressive thing was the
zero-cost branching implementation. We now use branches aggressively.
Very aggressively. We no longer have a trunk - just branches and tags
- and we have subcategories of branches: build, feature, historical,
personal, and so forth. Perforce could not have handled what we do,
and CVS... well, you never realize how limiting your tools are until
you replace them.
There were challenges. Initially, cvs2svn required some rather extreme
tweaking, and the requirement that each developer edit the config
settings for their svn:mime-type auto-assignment is rather painful. I
had to write our own merge scripts - there are some rather glaring
flaws in svnmerge, not the least of which is the all-on-one-line
format of the property it sets on the root of the branch. There is no
way to migrate a feature branch from one base to another with
svnmerge... something I had to write into our script... and
server-side hooks can slow things down a bit. Still, svn has been a
blessing, and it keeps getting better. And TortoiseSVN (which we use
for Win32 and Win64 development) and, for our handful of Java
developers, Subversive (we tried Subclipse, but liked the refactoring
integration in Subversive better) are both remarkable interfaces.
We're a deep-and-dirty C++ shop, so our unix (and OSX) developers are
mostly command-line junkies, but even there, the scriptability and
hookability of svn have led to a wealth of tailored in-house
improvements. And with the 1.4 series (aside from one _really_ nasty
bug with utf8 content on the command line on Win32, which will be
fixed in 1.4.3, hurry up, hurry up, hurry up!!! *clenched legs and
hopping*) TortoiseSVN even allows mandated format of bug and feature
tracking integrated comments, which removes a major item from our
to-do list.

Nathan F. Yospe

Lead developer, core library and cross platform development, unicode, and i18n
SAP Labs, MDM group, Los Angeles

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 11 06:26:52 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.