Subversion vs AccuRev

[Bryan Wilkins]

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”.

 

This is a quote from one of AccuRevs Senior Developers/Marketers, how does the group feel about this statement.

 

I’d highly suggest you take a thorough evaluation of AccuRev to realize the true value of the technology and the benefits.  I was an evaluator just like you…then a customer… and now a believer.   I’ll never go back to a branch-based system [cvs/svn/p4/cc/git/etc].  Never.  Streams are just so natural for managing software development.  In the same way that OO paradigm trumped Functional programming, streams are trumping branches [in fact, the stream inheritance model is… OO….].

 

I would like to get some of the users group opinions on AccuRev. AccRev is giving our CM their opinions and thoughts about Subversion (of course they are biased toward AccuRev, how else would they stay in business), but what are yours?

 

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

 

Another concern we have as a group is preserving our history. When we moved from CVS to SVN our entire code base history was preserved (via cvs2svn), everything I can see is that if we move to AccuRev we can only take “snap-shots” of the SVN repo at particular revisions and then “import” that exact revision into AccuRev, (can’t “dump” our svn repo and then read it back into AccuRev) do you know if that is the case?

 

If our CM forces this move upon us and then down the road we find out that AccuRev was not the expected “bang for your buck” and we move back to Subversion do you know if you can “dump” the AccuRev repo and then read it back into a SVN repo?

 

The majority of the developers I work with would like to stay with Subversion, but we are getting the feeling that our opinion might not matter. Some help from this group with a “why stick with Subversion” would be great. Suggestions other then “Subversion is free v AccuRev is expensive” would be beneficial as we have already brought this up with our CM and he doesn’t see that as a valid reason.

 

Thanks for your help, we are really looking for opinion to keep our CM from forcing this move upon us.

 

---------------------------------------------

Bryan Wilkins

Software Engineer

---------------------------------------------

 

[Stephen Connolly]

Eeeek!

Run away from AccuCrap as fast as you can.

We migrated from AccuCrap to Subversion because it is a pile of crap.

It has this seductive model about layered streams and how you can promote from each stream upwards.... in practice you can never trust promoting changes will have the correct effect.

I have promoted files only to have them disappear from the stream I am promoting into as well as from the stream I am promoting from... only to be replaced by another version.

I ended up writing an AccuCrap to Subversion conversion utility.  As this was done on work's dime I cannot share it with the world, but I will say this... after digging through the AccuCrap metadata, I would _never_ use AccuCrap at all.

There are the versions that we "kept" which AccuCrap refuses to give us back...

There are sections of our history which AccuCrap can only give a guess as to what the repository looked like (due to problems with the metadata)

Do not use AccuCrap

-Stephen

2009/10/8 Bryan Wilkins <bryan....@sdl.usu.edu>

[James Talbott]

Stephen,

You are entitled to your opinion about AccuRev and I will not attempt to change your mind, but the statements you make below are patently false.

> in practice you can never trust promoting
> changes will have the correct effect.
>
> I have promoted files only to have them disappear from the stream I am
> promoting into as well as from the stream I am promoting from... only to be
> replaced by another version.
>

> There are the versions that we "kept" which AccuCrap refuses to give us
> back...
>
> There are sections of our history which AccuCrap can only give a guess as to
> what the repository looked like (due to problems with the metadata)

I can guess at what company you work for as I am only aware of a single customer who has ever migrated from AccuRev to SVN, and that was at the behest of an executive who is no longer even with that company. I would encourage Bryan to continue working with the excellent resources AccuRev provides to allow them to fully evaluate AccuRev's capabilities. At that point, if it isn't for your organization, as long as you made a fair decision we support it. But please be aware that the FUD Stephen is spreading is not the experience of 99.9% of our customers, and is in fact probably caused by a lack of education and interest on their part to adopting the solution.

Regards,
~James Talbott
Senior Systems Engineer
AccuRev, Inc.

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

To unsubscribe from this discussion, e-mail: [users-un...@subversion.tigris.org].

[Dextrous]

On Thu, Oct 8, 2009 at 10:13 PM, James Talbott <jtal...@gmail.com> wrote:

Stephen,

You are entitled to your opinion about AccuRev and I will not attempt to change your mind, but the statements you make below are patently false.

> in practice you can never trust promoting
> changes will have the correct effect.
>
> I have promoted files only to have them disappear from the stream I am
> promoting into as well as from the stream I am promoting from... only to be
> replaced by another version.
>

> There are the versions that we "kept" which AccuCrap refuses to give us
> back...
>
> There are sections of our history which AccuCrap can only give a guess as to
> what the repository looked like (due to problems with the metadata)

I can guess at what company you work for as I am only aware of a single customer who has ever migrated from AccuRev to SVN,

  
was that a joke or you are serious......I personally know couple of companies  who moved from AccuRev to SVN....obviously I can not name them and I was kind of part of that migration.
 

and that was at the behest of an executive who is no longer even with that company.  I would encourage Bryan to continue working with the excellent resources AccuRev provides to allow them to fully evaluate AccuRev's capabilities.  At that point, if it isn't for your organization, as long as you made a fair decision we support it.  But please be aware that the FUD Stephen is spreading is not the experience of 99.9% of our customers,

How do you prove that what Stephen is saying is FUD and what you are saying is correct.. 

 

and is in fact probably caused by a lack of education and interest on their part to adopting the solution.

Wow what a lame excuse.....I don't believe even after paying some one will do that.....

--
Vishwajeet Singh
+91-9657702154 | dextr...@gmail.com | http://singhvishwajeet.com
Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet

[James Talbott]

Vishwajeet,

I'm not interested in starting a flame-war between SVN and AccuRev.  I'm merely stating that Stephen's claims are able to be demonstrably proven false, although clearly a newsgroup forum isn't the place where that would happen.  I'm also stating that I am only aware of a single customer who was using AccuRev who migrated away to SVN.  Others could have done so without my knowledge, but based on our 95% plus renewal rate, they would be few and far between, and no one of significance.  Lastly, my message was intended to be for Bryan so that he will continue to avail himself of the services AccuRev provides him to help his organization make an educated decision, as opposed to listening to the opinions of someone who clearly has a biased agenda.  Unlike many of the zealots out there, AccuRev does not pretend to be the solution for everyone.  However, should not those considering the option evaluate for themselves instead of basing their decision on unsubstantiated claims?

Best regards,

~James

[Bolstridge, Andrew]

There was a post to the dev list about this. Something for the future for SVN to support, so why go with the cost, effort, training, loss of history, re-evaluation, etc, when SVN may support the big fancy feature of Accurev anyway…. (well, that’s the spiel to use on management J).

 

http://svn.haxx.se/dev/archive-2009-08/0418.shtml

 

Streams are branches that are automatically updated with the parent branch’s changes. Which strikes me as incredibly dangerous. (sure, it’s got some buzzwords about ‘inheritance’ and ‘OO’ but that’s just to confuse the issue in the minds of management) Would you really want a parent or child branch getting updated with someone else’s code before you’re finished? I certainly wouldn’t. And yes, merging is difficult – that’s because you’ve changed code, there is *no* magic tool to automatically merge your changes with someone else’s (beyond simple changes).

 

Here’s  a link to a post (on the Mercurial lists) that describe the potential problems with stream-based development from a conceptual POV. http://www.selenic.com/pipermail/mercurial/2008-January/016362.html

 

 

I’d say that while Accurev seemed quite good (I evaluated it and some others for some time just before the credit crunch persuaded us to go with SVN) it’s not so vastly better that it is a must-have replacement for SVN. If you were using VSS, for example, I’d recommend you follow your CM’s lead, but in this case you’re just making work for yourself when there’s no need to. The question ‘why stick with SVN?’ needs to be reversed as ‘why move away?’.

 

If you really want to keep your CM occupied, perhaps you need to suggest a full evaluation of some alternative SCMs… mention Microsoft’s TFS and Clearcase. Nobody can reasonably say they’ll only evaluate 1 single provider without looking biased and stupid, and evaluating CC will keep him out of trouble for years J

 

If you want a more positive approach, suggest other areas where productivity could be improved, like setting up a CI server, better bug tracking or workflow (eg Collabnet’s Teamforge). Those things would provide far more benefits than simply changing one SCM for another, especially if you’re happy enough with the one you’ve got.

 

[Brett Coon]

My company (which shall remain nameless) currently uses both AccuRev and SVN, using both Windows and Linux clients for each.  I believe the history is that they started with SVN, then hired a fairly senior (technical) manager who was a big fan of AccuRev and convinced the company to switch.  AccuRev was purchased, the software and hardware teams copied their SVN repositories to AccuRev (with no transfer of history), but the hardware team hit some problems and soon switched back to SVN for design files (but not for documents).  I believe the intent is to switch everyone to AccuRev once the issues get worked out, whatever they were, though I'm not certain this will actually happen.  The AccuRev per-seat cost is quite a lot, and there isn't complete agreement it's worth it.

I have used AccuRev some, and SVN more.  I generally liked what I saw of AccuRev, and I particularly like how easy it is to checkpoint local changes ("keep") before pushing them upstream to become visible to other users ("promote").  I like the notion of streams, and the AccuRev GUI makes it really easy to move your workspace from one stream to another, which helps avoid a plethora of workspaces.  I don't really like SVN's approach to branches and tags much (especially tags), but for basic revision management it gets the job done.

I've previously used Perforce, CVS, and RCS.  At the moment, AccuRev is probably the one I like best, but given that it's also the one I've used least, this could be a grass-is-greener type thing.  And it's a whole lot more expensive than SVN...

-Brett

--
Brett Coon - brett...@gmail.com - http://brettcoon.smugmug.com

[Stephen Connolly]

Sent from my [rhymes with tryPod] ;-)

On 8 Oct 2009, at 18:04, James Talbott <jtal...@gmail.com> wrote:

Vishwajeet,

I'm not interested in starting a flame-war between SVN and AccuRev.  I'm merely stating that Stephen's claims are able to be demonstrably proven false,

I have still got the depots with the "lost" versions which accurev says were kept but refuses to give back

I have still got the depots with the artifacts that disappear when promoted

I have still got the depots where the state of all streams at specific points in time is inconsistent (ie if I recreate a snapshot of the exact same stream at the exact same time I get a different view from the existing snapshot... ok thus only affects a 3hour period in the entire 7 year history but I stand by my claims/facts)

although clearly a newsgroup forum isn't the place where that would happen.  I'm also stating that I am only aware of a single customer who was using AccuRev who migrated away to SVN.  

well we will not be renewing

Others could have done so without my knowledge, but based on our 95% plus renewal rate, they would be few and far between, and no one of significance.

that may be because once you sip the accurev koolaid it is virtually impossible to transfer your history out of accurev. (i managed to do it, but it took a lot of effort and, fortunately for you, I cannot share the tools I created with the world)

 Lastly, my message was intended to be for Bryan so that he will continue to avail himself of the services AccuRev provides him to help his organization make an educated decision, as opposed to listening to the opinions of someone who clearly has a biased agenda.  

I would think that the tone of my original message made it quite clear. I _hate_ accurev as an SCM.

I used to like it until I dug deep and wrote a conversion utility... when you see what the data model is under the hood... well have a look yourself and make up your own mind. my opinion is known

Unlike many of the zealots out there, AccuRev does not pretend to be the solution for everyone.  However, should not those considering the option evaluate for themselves instead of basing their decision on unsubstantiated claims?

I state what we found. for 95% of the problems we found, I know why accurev is behaving in the counterintuitive way that it is... if I were to explain, you would probably say, but that is Functions as Designed. I'd say the design is crap

[John Waycott]

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.

[Andreas Magnusson]

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”.
>
>
>
> This is a quote from one of AccuRevs Senior Developers/Marketers, how
> does the group feel about this statement.
>
>
>

> */_I’d highly suggest you take a thorough evaluation of AccuRev to

> realize the true value of the technology and the benefits. I was an
> evaluator just like you…then a customer… and now a believer. I’ll
> never go back to a branch-based system [cvs/svn/p4/cc/git/etc]. Never.
> Streams are just so natural for managing software development. In the
> same way that OO paradigm trumped Functional programming, streams are

> trumping branches [in fact, the stream inheritance model is… OO….]._/*

>
>
>
> I would like to get some of the users group opinions on AccuRev. AccRev
> is giving our CM their opinions and thoughts about Subversion (of course
> they are biased toward AccuRev, how else would they stay in business),
> but what are yours?
>
>
>
> Are there any users in the group that have used AccuRev in past jobs and
> what are their thoughts?
>
>
>
> Another concern we have as a group is preserving our history. When we
> moved from CVS to SVN our entire code base history was preserved (via
> cvs2svn), everything I can see is that if we move to AccuRev we can only
> take “snap-shots” of the SVN repo at particular revisions and then
> “import” that exact revision into AccuRev, (can’t “dump” our svn repo
> and then read it back into AccuRev) do you know if that is the case?
>
>
>
> If our CM forces this move upon us and then down the road we find out
> that AccuRev was not the expected “bang for your buck” and we move back
> to Subversion do you know if you can “dump” the AccuRev repo and then
> read it back into a SVN repo?
>
>
>
> The majority of the developers I work with would like to stay with
> Subversion, but we are getting the feeling that our opinion might not
> matter. Some help from this group with a “why stick with Subversion”
> would be great. Suggestions other then “Subversion is free v AccuRev is
> expensive” would be beneficial as we have already brought this up with

> our CM and he doesn’t see that as a valid reason..

>
>
>
> Thanks for your help, we are really looking for opinion to keep our CM
> from forcing this move upon us.
>
>
>
> ---------------------------------------------
>
> Bryan Wilkins
>
> Software Engineer
>
> ---------------------------------------------
>
>
>

Well', I've had to use AccuRev at work, and I just don't like it. First
of all they seemed to have to redefine all the actions we're used to.
Like "Delete". Uh uh, it cannot be named "Delete", so we call it
"Defunct". Now, all you Americans probably have a good graps what that
really means, but why not call it "Delete"?
They have a bad UI, a bad Eclipse integration and no working Windows
Explorer integration (on a 64-bit version that is).
Subversion has it all. I've come to the conclusion that to gauge the
maturity of a SCM product *on Windows* simply see if they have a working
Windows Explorer integration for 64-bit XP/Vista.

Oh, and these streams with "auto-merge", pure evil. Because everything
works automatically until you have a merge conflict, then you have to do
it by hand anyway. So why not merge/synch when you feel up for it/ready?
That way you know to look for conflicts, instead of having to fire up
the UI, and look for overlaps, oh, and don't forget to look for
deep-overlaps also. There is probably a good *technical* reason for the
two, but as a user I just don't care.

Sorry, didn't really mean to go off the deap end here...

/Andreas

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

[Purple Streak]

2009/10/11 Andreas Magnusson <andreas.ch...@home.se>:

>
> Well', I've had to use AccuRev at work, and I just don't like it. First
> of all they seemed to have to redefine all the actions we're used to.
> Like "Delete". Uh uh, it cannot be named "Delete", so we call it
> "Defunct". Now, all you Americans probably have a good graps what that
> really means, but why not call it "Delete"?
> They have a bad UI, a bad Eclipse integration and no working Windows
> Explorer integration (on a 64-bit version that is).
> Subversion has it all. I've come to the conclusion that to gauge the
> maturity of a SCM product *on Windows* simply see if they have a working
> Windows Explorer integration for 64-bit XP/Vista.
>
> Oh, and these streams with "auto-merge", pure evil. Because everything
> works automatically until you have a merge conflict, then you have to do
> it by hand anyway. So why not merge/synch when you feel up for it/ready?
> That way you know to look for conflicts, instead of having to fire up
> the UI, and look for overlaps, oh, and don't forget to look for
> deep-overlaps also. There is probably a good *technical* reason for the
> two, but as a user I just don't care.

We had a good look at SCM systems before moving to SVN and had similar
views. Accurev has a lot of promise, but it costs a lot and for us
the UI just wasn't there, it's just not very usable (which is a shame
as I think the whole eclipse ui was quite new. They should just sit
and watch new users try to use it). I could just imagine people
coming to me and complaining that they can't use and don't understand
it so why did we pay $1000s for it. I _think_ there's an almost really
good backend there (but again needs some tweaks so you can reuse names
of streams/workspaces) but it just doesn't quite warrant the price
IMHO.

The terminology is just different from anything else for no reason
sometimes (streams vs branches I almost get, but the rest if just
gratuitous change).

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

[Deepak V.]

We had been Subversion users for over a year, but we ran into difficulties with the team in India as well as making changes to the release at the end of each 2-week iteration. We found that merging was a real problem for us, and it often lead to regressions and other mistakes. We evaluated a number of tools, including Perforce, ClearCase and AccuRev, and we ended up going with AccuRev (it was primarily a management decision). I had actually wanted to stay on Subversion, but I was over-ruled.

One of the keys to deploying AccuRev here was making sure everyone was trained (it took 1-2 hours to get each developer up to speed on our process in AccuRev). The new terminology, as noted here, was indeed a pain in the neck to learn. I really don't understand why they can't use standard terms.

Their stream architecture has definitely helped us manage multiple releases, and it keeps everthing straight without the need for last minute merging. This was the isue that led us to look at new tools in the first place, and it has delivered.

Also, their support has been excellent. It took us about a week to do the full transition, and they had someone onsite most of that time to deal with issues like integration into our JIRA system.

In summary, while I do generally prefer free tools, I believe that we are getting good value from AccuRev given the lack of issues we've had since we made the switch.

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

[Deepak V.]

and it has delivered.

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

[Florian Weimer]

* Bryan Wilkins:

> I would like to get some of the users group opinions on
> AccuRev.

Are AccuRev branches like Aegis branches, where changes on your base
branch shine through almost immediately?

Most branching models are equivalent. There used to be a time when
people got worked up about the distinction between tree snapshots and
changesets, but this seems to be over by now (good riddance).

--
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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

[Stephen Connolly]

2009/10/21 Florian Weimer <fwe...@bfk.de>

* Bryan Wilkins:

> I would like to get some of the users group opinions on
> AccuRev.

Are AccuRev branches like Aegis branches, where changes on your base
branch shine through almost immediately?

You have to do an update... which requires keeping all your local changes first... which in my experience means that people are reluctant to do an update until all their changes are ready... might have something to do with my commit early, commit often development style though ;-) [small changes are easier to merge with the accurev merge tool, so if you commit loads of small changes and update regularly, merging is never a problem... if you update rarely, merging is a big pain, so you update even less often]
 

[Florian Weimer]

* Stephen Connolly:

> 2009/10/21 Florian Weimer <fwe...@bfk.de>
>
>> * Bryan Wilkins:
>>
>> > I would like to get some of the users group opinions on
>> > AccuRev.
>>
>> Are AccuRev branches like Aegis branches, where changes on your base
>> branch shine through almost immediately?
>>
>
> You have to do an update... which requires keeping all your local changes
> first... which in my experience means that people are reluctant to do an
> update until all their changes are ready...

Okay, then I don't see what makes AccuRev's model so different.
Perhaps it's just a rehash of one of the older debates (where folks
were essentially debating whether a line is a set of points or a
solution of an equation).

Aegis was actually different: in general, your working copy (which is
not really yours alone) immediately reflects changes as they are
integrated into the base branch. (Local changes to updated files
prevent this immediate visibility.)

--
Florian Weimer <fwe...@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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

[Toby Thain]

On 8-Oct-09, at 3:41 PM, Brett Coon wrote:

My company (which shall remain nameless) currently uses both AccuRev and SVN, using both Windows and Linux clients for each.  I believe the history is that they started with SVN, then hired a fairly senior (technical) manager who was a big fan of AccuRev and convinced the company to switch.  AccuRev was purchased, the software and hardware teams copied their SVN repositories to AccuRev (with no transfer of history), but the hardware team hit some problems and soon switched back to SVN for design files (but not for documents).  I believe the intent is to switch everyone to AccuRev once the issues get worked out, whatever they were, though I'm not certain this will actually happen.  The AccuRev per-seat cost is quite a lot, and there isn't complete agreement it's worth it.

I have used AccuRev some, and SVN more.  I generally liked what I saw of AccuRev, and I particularly like how easy it is to checkpoint local changes ("keep") before pushing them upstream to become visible to other users ("promote"). 

Quite a number of open source VCS offer this capability, particularly the "distributed" ones including Bazaar, and even Subversion with extensions.

--Toby