[olug] Looking for some svn help

[Christopher Cashell]

On Wed, Apr 25, 2012 at 6:35 PM, Jeff Hinrichs - DM&T
<jeffh at dundeemt.com> wrote:
> **side note**
> And for anyone else who wants to chime in with "Switch to X", it is not
> always that simple.  Unless you can justify the ROI on switching X for
> non-trivial  projects "switch to x" is a non-starter.  If you are a one man
> show than switching vcs's might be akin to changing socks, in more complex
> environments there are frequently more factors to consider.  As a starting
> point, if you can't demonstrate a minimum of 10x improvement, I am not
> interested.  10x is the bare minimum to cover logistical expenses of
> migration and retraining.

Well said, Sir.

While git (and to lesser extents, mercurial, bazaar, fossil, etc) are
the new hotness in source and revision control, Subversion is still
going (very) strong in the corporate world.  Outside of Open Source
and startups, Subversion is probably the most common version control
system in use.

Something that has to be remembered is that in the corporate world,
there are a lot of factors that affect the choice of version control
system, and coolness, trendiness, and even modern advanced features
rarely play into it.

Among the things that do need to be considered:

1. Platform use.  git support for Windows is still pretty weak.  If
your team is doing all, most, or even just a significant minority of
their development on or for Windows, git is likely not going to be
your best option.

2. Tool support.  Subversion, by virtue of having been around a lot
longer, has good integration with many development environments and
development tools.  If you are making use of or need these tools, you
will want a version control system that works well with them.

3. Automation support.  Again, due to it's ubiquity in the corporate
world and it's longer history, subversion is supported by a lot of
automated tools (build systems, test systems, deployment systems,
etc).  If you have a lot of build or deployment automation built
around subversion (or some other version control system), changing can
be a very significant undertaking.

4. Existing experience.  The larger the team, the more this matters.
If you have 1-2 people, it's easier to switch to a different system.
If you've got a team of 10 or 20, that's a lot of people who need to
be retrained, both on the version system, and the tools and
infrastructure around it.

5. Corporate policies.  While a lot of people find distributed version
control systems to be wonderful (I'm a fan, myself), the corporate
world has different goals and requirements.  Among them is a stronger
desire for control.  By it's centralized nature, the organization has
more control over the code repository with subversion than with a
distributed system.

6. Time resource constraints.  If you've already invested the time and
resources to install, setup, configure, and implement an existing
version system, there will need to be a very definite rationale for
switching.  Every minute spent installing and setting up the new
system, training people for it, integrating it with existing tools and
systems, etc., is time that could have been spent developing actual
code.  Most development teams aren't exactly swimming in free time.
;-)

7. Inertia.  In the corporate world, Subversion is the solid, safe
choice.  It's strengths and deficiencies are well known and
understood.  Most corporations are risk averse, with some good reason,
so they're going to go with what's "standard" in the industry.  Same
reason that so much development is done in Java.  It's easier to hire
people who know it and can use it.

> Jeff Hinrichs

-- 
Christopher