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
> <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=2410497
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-23 04:01:15 CEST