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

Re: Subversion vs AccuRev

From: John Waycott <javajohn_at_cox.net>
Date: Fri, 9 Oct 2009 07:50:59 -0700

On Oct 8, 2009, at 8:00 AM, Bryan Wilkins wrote:

>
> The company I work for has been using Subversion happily/
> successfully for the past two years. A couple of months ago a new
> Configuration Manager was hired. For that last two weeks he has been
> “hot and heavy” into webinars and evaluations of AccuRev. He really
> thinks that it will “increase” productivity. The AccuRev marketing
> has really been selling him on their “stream” paradigm vs. the
> traditional “branches” paradigm. AccuRev says that that “stream”
> paradigm is the “way of the future”.

> Are there any users in the group that have used AccuRev in past jobs
> and what are their thoughts?
>

I would ask your CM what it is that he's trying to accomplish? If
everyone is happy using SVN, what problem is moving to Accurev going
to solve? Are developers making mistakes with SVN? The only reason to
move to another tool is to solve a problem that you can clearly show
is really happening. If he can demonstrate that your productivity is
hampered by SVN, then by all means, take a look at other tools. Make
sure he takes into account the cost of training, early mistakes that
will be made with an unfamiliar tool, etc.

I evaluated several tools to replace a hodgepodge of PVCS,
SourceSafe, CVS and plain-old zip archiving. This was several years
ago, so things may have changed. After my evaluation, I thought
Accurev was the leader technically. My decision though was to go with
SVN.

I could not justify spending the money (especially long-term) on
Accurev. It did not provide enough advantage over SVN to justify the
cost. SVN is easy to administer, and we had expertise in house to do
the installation. The main advantages Accurev had at the time were
easy installation, a very graphical, easy to use interface and very
flexible security model. Our needs for security are very black and
white, so SVN was just fine for our needs. Other development teams
may need something more flexible. The graphical interface is great
visually, but during daily operation, it is not really necessary. I
liked the streams approach, but through good SCM practice, branches
are just fine too.

I also made the assumption at that time, based on my experience with
open-source, that SVN was going to get very popular. I looked at what
companies were currently using it, what problems people were having,
how they were getting solved, and came to the conclusion that SVN was
a risky but good choice. Today, we have development partners who are
all familiar with SVN. There is a great advantage to having a tool
that is familiar to most developers.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2405563

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-09 16:51:58 CEST

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.