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