[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: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Thu, 8 Oct 2009 18:13:18 +0100

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




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.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-08 19:14:40 CEST

This is an archived mail posted to the Subversion Users mailing list.