[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: korebantic <korebantic_at_gmail.com>
Date: 2007-01-11 18:44:25 CET

Nathan,

You have peaked my curiosity in terms of the usage pattern you are employing
with subversion, and how you automated the merge process. Regardless, thanks
for your input.

On 1/11/07, Nathan Yospe <nyospe@gmail.com> wrote:
>
> 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
> overhead.
> 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.
>
> Regards,
> Nathan F. Yospe
>
> Lead developer, core library and cross platform development, unicode, and
> i18n
> SAP Labs, MDM group, Los Angeles
>
Received on Thu Jan 11 23:30:34 2007

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