The AccuRev CLI – Going beyond SCM

By Ryan LaNeve, AVI-SPL

Much has been written on this blog already regarding the ease with which AccuRev allows you to tailor your development process without having to fight with your SCM software. While I could offer yet another account of how simple and straightforward it is to manage our particular process using AccuRev, instead I thought I’d take a few minutes to point out some of the things we’ve done using the tool’s command-line interface and its ability to output results formatted as XML.

Of the various tools we have created over the years, the two we find most useful are what we call “AccuLoad” and “SQL Object Scripter”. The former pulls data out of AccuRev, while the latter puts data into AccuRev. Both were developed in a matter of hours thanks to the extremely intuitive command-line interface which AccuRev provides. Let’s take a closer look at each.

We’ll start with our “SQL Object Scripter”. Anyone whose development efforts involve a database server knows how difficult it is to maintain change logs for the “code” kept within the database. There are a number of “best practices” with regards to maintaining this information within an SCM, but in our experience they are all too time-consuming and involved, which leads to one or more members of the team either forgoing the process due to time constraints or just ignoring the process all together. Maybe we’ve just become spoiled by AccuRev allowing us to work exactly the way we want and otherwise staying out of our way, but we now have a hard time following any procedure which requires us to change the way we do things.

So one day a couple of us sat down and decided to find a new solution. We felt that, at a minimum, what we really wanted was to be able to view changes over time for our database objects, such as tables, views and stored procedures. We knew that if we could just get each change into AccuRev some of our issues would immediately disappear, but we found it too difficult to require the entire team to manually create every script and then manually promote that script into our SCM. We decided that what we needed was a tool that could simply detect changes to our database objects and automatically store those changes within AccuRev. Again, thanks to the simplicity of AccuRev and its CLI, our “SQL Object Scripter” tool was born in a matter of hours. We now have a record in AccuRev of (almost) every change made to any database object we care about, which then allows to use the features of AccuRev to view the history of any object, the differences between any versions of any object and even an annotation of any object to see who is responsible for the make-up of the object. The solution consists of a few parts: a SQL Server table to store DDL change event details, with a DDL trigger on the various databases we care about. The trigger fires whenever a DDL event occurs, such as the creation or alteration of a table, view or stored procedure, and the details of the event get logged to a table. Our custom console app is then scheduled to run every few minutes and checks the table for any records. When a record is found, the console app scripts out the definition of the object to a file and then uses the AccuRev CLI to add/keep/promote the file to our “SQL Scripts” depot – whatever is appropriate depending on whether the object is brand new or pre-existing and has been changed. The AccuRev commands all run within the context of whichever user made the change in the database itself, so all of our AccuRev transactions are associated with the correct team member. While this solution is not optimal and does not provide as much traceability as having each developer maintain and promote database change scripts themselves, we have found it to be an excellent interim solution which was extremely easy to put together.

Another of our tools is the one we call “AccuLoad”. The purpose of this tool is to pull various bits of information out of AccuRev and load that information into a database. We then use the information in the database from several other applications. The tool is a console application which runs in a couple of different modes, but the primary mode is run via an AccuRev trigger. Whenever a promote happens in one of our depots, our custom trigger runs and fires up our console app, passing in a few details such as the name of the depot, the name of the stream and the transaction number of the promote. AccuLoad then takes this information and makes various calls to the AccuRev CLI to gather more details, such as which elements were included in the promote, the version numbers of each of those elements, the user who performed the promote, etc, etc… Additionally, a diff is run against any changed elements, and those details are stored in the database as well. Gathering all of this information from AccuRev was extremely simple thanks not only to the intuitive nature of the functionality exposed by the AccuRev CLI, but also thanks to the option of having the results returned as XML. While I’m sure it would have been possible to create such a tool using any SCM, I doubt we would have ever found the time to do so had we not been fortunate enough to have AccuRev as our SCM. It was, again, only a matter of hours from the time we came up with the idea for AccuLoad and the time our first promotions were being logged in our database.

Having this database detailing the activity in our SCM, we were then able to create several other tools to utilize the information, such as one we call “AccuBrowse”, seen below. This web-based application allows us to browse the database and view any transaction within any stream of any of our depots, and see who performed the promote, the comments supplied during the promote, the elements included in the promote and the differences for any changed element. I should mention that much of this functionality is probably available in the AccuRev Web Interface, though we have not actually used that tool provided by AccuRev. Ours was created a couple of years ago and suits our needs. Beyond just allowing us to browse our SCM history via a web-interface, our database also allows us to perform some analysis, such as frequency of change for elements within a specific depot or stream, which allows to keep tabs on classes within our systems which may have too much responsibility. We can even run queries against the data to find “problematic” code, such as those files most often included in promotions which cause a failed build (not that our builds ever fail, of course…).

In summary, there are a myriad of fantastic features and functionality within AccuRev which make it a great fit as an SCM for any development environment. Once you’ve got your core needs taken care of by the out-of-the-box functionality, I encourage you to explore what can be done with the provided CLI and its XML-formatted output. In our experience, if you can imagine it, you can build it with AccuRev in no time at all.

Our custom AccuBrowse application, viewing a transaction involving a SQL Server stored procedure:


6 Responses to The AccuRev CLI – Going beyond SCM

  1. Víctor says:


    I’ve read your article, I think it is so interesting because you can get information like SCM’s measures or metrics in order to improve the SCM process. Have you already used it to get measures or metric? I would like to know where could i get a version of that program in order to test it. Or is it a private version?


  2. […] Ryan shows off some great stuff with users checking in code that automatically kicks off a build and even updates the product version number to reflect the latest transaction number from AccuRev. Ryan recently blogged about some of the cool things he’s done using the AccuRev command-line interface (CLI) and its ability to output results formatted as XML: The AccuRev CLI, Going Beyond SCM. […]

  3. Fitz says:

    Sounds good – but really, how is that different than just about any other open source scm tool?

    My experience has been that other tools are more flexible with things like a powerful CLI and then a great thin GUI layer (think SVN & Tortoise SVN).
    It seems as though accurev goes the other way, which many big tools do, which is put the functionality in the gui, then expose some to the CLI. Which always frustrates the heck out of power-users since inevitably there is something the GUI can do that the CLI can’t. Whereas every operation the Tortoise SVN GUI does, you can do through the command line.

    SVN for eaxmple, can return it’s information as XML – but you can also get a library wrapper for just about any scripting language that lets you work at an even tighter integration level than the CLI if you want. Just seems like there is more to the story.

  4. Ryan LaNeve says:

    How this is different than “just about any other open source scm tool” would depend entirely on which tool, whether its CLI allowed output to XML and whether or not using the CLI was as intuitive as AccuRev’s. For some systems – open source or otherwise – I’m sure that would be the case. Nothing about this post was intended to suggest that *only* AccuRev provided such functionality. I thought the sentence beginning “While I’m sure it would have been possible to create such a tool using any SCM…” would make that clear.

    Whether or not “more flexible” is defined by a powerful CLI and a thin GUI, or a powerful GUI and a thin CLI is a personal preference, though in my opinion the question doesn’t apply here. AccuRev has both a powerful GUI (far more powerful than any open source scm we’ve ever seen) as well as a powerful CLI which exposes all functionality that could have been performed by the GUI.

    Wrappers for scripting languages would certainly be nice.

  5. davidpthomas says:

    Hi! Great feedback. To clarify, the AccuRev CLI (client) is the defacto API for communicating with the AccuRev server [handling socket & txn mgmt]. Options include XML ($accurev xml) or traditional CLI arguments ($accurev ). The AccuRev GUI actually calls the CLI behind the scenes using XML in & out. Thus, anything you can do in the GUI, you can do in the CLI! AccuRev started out as a Unix-only tool back in the day, and the CLI interface shows its roots.

    For those using the XML in/out format, you’ll be glad to know that the XML output for most commands is very flat making it trivial to convert into a hash (of hashes) structure for programmatic interpretation.

    Anyone else using ruby?


  6. […] code control tools they may have to write scripts, manage configurations or interact with a command line interface to be able to get their work done. This type of interaction will likely not work well for these […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: