You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bryan Wilkins <br...@sdl.usu.edu> on 2009/10/08 15:00:37 UTC

Subversion vs AccuRev

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

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

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

RE: Re: Subversion vs AccuRev

Posted by "Deepak V." <bc...@gmail.com>.
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

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

RE: Re: Subversion vs AccuRev

Posted by "Deepak V." <bc...@gmail.com>.
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=2407129

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

Re: Subversion vs AccuRev

Posted by Stephen Connolly <st...@gmail.com>.
Sent from my [rhymes with tryPod] ;-)

On 8 Oct 2009, at 18:04, James Talbott <jt...@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

>
> Best regards,
> ~James
>
>
> On Thu, Oct 8, 2009 at 12:52 PM, vishwajeet singh <dextrous85@gmail.com 
> > wrote:
>
>
> On Thu, Oct 8, 2009 at 10:13 PM, James Talbott <jt...@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 | dextrous85@gmail.com | http://singhvishwajeet.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
>

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

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

Re: Re: Subversion vs AccuRev

Posted by James Talbott <jt...@gmail.com>.
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


On Thu, Oct 8, 2009 at 12:52 PM, vishwajeet singh <de...@gmail.com>wrote:

>
>
> On Thu, Oct 8, 2009 at 10:13 PM, James Talbott <jt...@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 | dextrous85@gmail.com | http://singhvishwajeet.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn:
> http://www.linkedin.com/in/singhvishwajeet
>

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

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

Re: Re: Subversion vs AccuRev

Posted by Dextrous <de...@gmail.com>.
On Thu, Oct 8, 2009 at 10:13 PM, James Talbott <jt...@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 | dextrous85@gmail.com | http://singhvishwajeet.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

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

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

RE: Re: Subversion vs AccuRev

Posted by James Talbott <jt...@gmail.com>.
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-unsubscribe@subversion.tigris.org].

Re: Subversion vs AccuRev

Posted by Toby Thain <to...@telegraphics.com.au>.
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

> 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
>
>
> On Thu, Oct 8, 2009 at 10:13 AM, Bolstridge, Andrew  
> <an...@intergraph.com> wrote:
> 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 - brett.coon@gmail.com - http://brettcoon.smugmug.com

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

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

Re: Subversion vs AccuRev

Posted by Brett Coon <br...@gmail.com>.
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


On Thu, Oct 8, 2009 at 10:13 AM, Bolstridge, Andrew <
andy.bolstridge@intergraph.com> wrote:

>  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 - brett.coon@gmail.com - http://brettcoon.smugmug.com

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

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

RE: Subversion vs AccuRev

Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
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.

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

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

Re: Subversion vs AccuRev

Posted by Stephen Connolly <st...@gmail.com>.
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 <br...@sdl.usu.edu>

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

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

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

Re: Subversion vs AccuRev

Posted by John Waycott <ja...@cox.net>.
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@subversion.tigris.org].

Re: Subversion vs AccuRev

Posted by Purple Streak <mr...@googlemail.com>.
2009/10/11 Andreas Magnusson <an...@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

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

Re: Subversion vs AccuRev

Posted by Andreas Magnusson <an...@home.se>.
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

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

Re: Subversion vs AccuRev

Posted by Florian Weimer <fw...@bfk.de>.
* Stephen Connolly:

> 2009/10/21 Florian Weimer <fw...@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                <fw...@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

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

Re: Subversion vs AccuRev

Posted by Stephen Connolly <st...@gmail.com>.
2009/10/21 Florian Weimer <fw...@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]


>
> 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                <fw...@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
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>

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

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

Re: Subversion vs AccuRev

Posted by Florian Weimer <fw...@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?

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                <fw...@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

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