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_at_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_at_subversion.tigris.org].
Received on 2009-10-08 21:42:27 CEST