Thoughts From The Trenches (Giant Brain Dump Incoming!)

You may also like...

5 Responses

  1. Happy AccuRevver says:

    As a developer at a company that adopted AccuRev a little over a year ago in replacement of a failed SVN instance, I can tell you that either you haven’t taken the time to figure out how the tool can help you or your company has not properly implemented it.

    The symptoms and problems you mention are _precisely_ the issues that AccuRev resolves! Afraid to update code? AccuRev allows that automatically, dramatically reducing the need to merge. Broken code base, won’t compile? Work in isolated streams yet still have the ability to deliver when your code is stable. Emailing when things are wrong? Use the visual nature of the stream browser to see what’s changed, what’s wrong, etc. You can’t figure out how to "blame" or look at Change Packages? Then you haven’t grasped what AccuRev takes only two hours in an online course to teach average folks.

    The terms they use are not obtuse; they have to be different because the methodology is different (and superior) from "common" source control. Again, takes just a few minutes to learn. AccuRev is so far ahead of rudimentary tools like Subversion that there really isn’t any comparison.

    I can appreciate your brain dump here, but you’re way off base with regards to AccuRev.

  2. Chuck says:


    I think that the fact that the number of job listings on Dice that include "AccuRev" as a requirement is in the single digits says a lot about how superior it really is 😉

    Some of the issues that I have with it include:

    * No listing of changesets. This is perhaps one of the most useful features of a source control system.

    * Many common commands (like file rename) require a command line operation.

    * While integration with an issue tracking system is usually a good thing, the issue tracking system itself is so severely neutered, I’m not sure why anyone would want to use it. The text entry box is a rather useless text box, incapable of adding formatted text, code blocks, etc). The commenting system is non-existent so developers and testers end up modifying the description and adding "[CHUCK 8/20] Did you try this?" and then followed by "[STEVE 8/21] No, not yet, let me try". This doesn’t make sense. Try Trac and see how much better an issue tracking system can be.

    * It’s slow. Very slow. SVN over HTTPS (across several states) is faster than AccuRev over the local network.

    * There aren’t many tools that integrate with it. Because of the popularity of source control systems like SVN and Mercurial, you’ll find that there are many tools that extend and integrate with them.

    * It’s nearly impossible to track external files because there’s no way to exclude files from the externals. Using TortoiseSVN with SVN, for example, you can set exclude paths for directories like \Debug or \obj or \bin (directories for your binary output). Every time do a check-in with new files, it’s a challenging 10 minute ordeal to find them in externals and add them to the depot.

    * The lack of expertise in AccuRev leads to severe productivity issues since on any given project, especially if you bring on consultants, only a very small number of people actually know what they are doing and how to handle the "advanced" use cases (AccuRev seems to have a very low bar for what it considers "advanced"). It means that certain resources become bottlenecks for resolving issues with the source control system on a near daily basis.

    * Even when using a separate stream, upstream changes get pushed down automatically. While this is handy, it also means that if you are working on an experimental/refactor branch with another dev separate of the main line of development, you may end up with a lot of conflicts when you update. In SVN and Mercurial, this type of merge is an explicit merge from one branch to another.

    * The UI is overly complex with way too many buttons and icons that make no sense. Who would intuitively think that a green lightning bolt means update?

    * When you do an update or commit, there isn’t a handy listing of what changed that you can use to view files, diff, view the log of the file, etc from a single list.

    * There doesn’t seem to be support for line-by-line SVN blame type functionality. Having lived with this in SVN, using a source control system that doesn’t support this is very annoying – it becomes difficult to figure out who put in a breaking change. Maybe this functionality exists? But the fact of the matter is that in working with three consultants from my company who have been on this project for two years, none of them can tell me how this is done. No one knows how to figure out who wrote a particular breaking change. To some degree, it almost doesn’t matter if it supports this feature or not. If it’s hard to use or obscure, it might as well not exist.

    These are just some of the complaints off the top of my head. I do agree that AccuRev is probably better for some scenarios and specific roles (like an integration manager), but for developers, it’s a kludgy, heavy, hard to use, poorly designed pain in the behind.

  3. Damon says:


    Open source systems are the norm in the industry, so it isn’t surprising that there are more listings on dice.

    If you want to see the change sets, just run history on either a file, stream, or depot as you need.

    Rename is available via right-click or the little RN icon in the GUI. What else do you go to the cli for?

    It shouldn’t be slow. Let your admin know about it or contact AccuRev support directly and they will help to troubleshoot.

    What would you like to integrate with?

    You can exclude external files with ACCUREV_IGNORE_ELEMS. Check the docs.

    The whole point of AccuRev is inheritance. But, if you don’t want files from other streams, just set a time basis on your stream and you will block it.

    A "what changed in my update" feature is a good idea. I’ll add it to the backlog.

    If you want "blame," that is the "annotate" command in AccuRev, available from the command line and the GUI right click. In the GUI, it supports a real-time slider which changes the content as you slide the slider.

    You may also want to look into which version you are currently on. We are always working hard to satisfy our users, check out the latest version! You may also want to check out our new web interface.

    If there are particular features you are looking for, a great place to write to make sure we hear you is on our forums (Support & Services/User Forum) .



  4. Chuck says:


    While your point is valid, that SVN will have a larger userbase, I think you’ve missed _my_ point: having a small userbase, even if it _were_ a superior product, means that it increases ramp-up time for new resources and creates resource bottlenecks in day-to-day development since few people are adept at using AccuRev and understand the peculiarities of the system.

    The larger userbase that SVN has means that it’s easier to onboard a new resource and that that resource is more likely to be proficient in SVN usage.

    With regards to integration of SVN, we need only look at TortoiseSVN (and likewise, TortoiseHg for Mercurial — both much easier to use and more intuitive than the desktop client for AccuRev) and Trac (for both SVN and Mercurial with a wide variety of plug-ins to support other source repositories). Other systems that AccuRev may plug into (say CruiseControl.NET) suffers from the fact that there is less community usage of such integration and thus less documentation when something goes wrong or an advanced scenario arises. Why put your team through that?

    Even more basic than that is usability: AccuRev lacks it. From the ambiguous buttons (all the same size? the most commonly used buttons need to be organized much better than they are now) to the straight out of 2001 look-and-feel as well as the overly simplistic and nearly useless ticket description/editor (come on, how hard can it be to add support for bold, italics, color, and code snippets? how about the ability to add comments outside of the description text box?), I don’t see much there is to like about AccuRev as a developer (again, I can see it as a much more attractive product from the point of view of an integration manager or the deployment team).

    Shell integration would be a nice addition as well. Why make people jump through the desktop client instead of a much more natural Explorer integrated solution?

  5. Damon says:

    Hi Chuck,

    I just realized that I forgot to thank you for spending the time to provide feedback at all. Thank-you.

    Can you elaborate on the button size issue? I’m not following.

    You’ll get a better editor in the near future, but in the web interface first. Check it out, it also has our new graphing and charting features.

    There is a shell integration, you can get it from our downloads page. It is under Other Downloads, AccuBridge, AccuBridge for Windows Explorer .

    We are currently adding tons of new features via the web interface every 2-3 months. Your input will definitely be part of that process.

    By the way, which IDE do you use?