![]() |
BX Land
Home to all things Bruce Grant
|
|
![]() |
Author: Bruce Grant, Jr. (BX)
Published: May 9, 2008
Reviewing the Accurev Source Code Management System
This article reviews the Accurev Source Code Management system, comparing it to the more well known Subversion product. It explores how a commercial product such as Accurev can remain viable in a version control world largely dominated by open source products.
I've used many source code management systems in my career including Visual Source Safe (back in the day and glad those days are over), CVS and Subversion. The company I'm now working for uses Accurev. I was very surprised they weren't using Subversion which I've been using for many years now. Subversion, if not leading, is taking off in the market. It enjoys excellent support in the majority of development tools out there and frankly I'd never heard of Accurev. Here's what I've learned about Accurev compared to Subversion.
I'm going to start with what isn't so great about Accurev, which unfortunately is a lot. First, Accurev is crazy expensive. I don't have the exact numbers but each engineer needs his or her own license before accessing the repository. Compare that to Subversion where the only cost is figuring out how to install it and that's a pretty significant detractor to adopting Accurev. Next, the visual tools Accurev provide feel arcane and fragile. I regularly hear engineers complain that Accurev somehow acted unpredictably or flat out broke. In reality I think Accurev is rock solid. The problem is that Accurev is a steep learning curve and engineers forget about the mechanics of Accurev. Here's an example. Yesterday I opened the Accurev tool and it told me it couldn't find my code. I looked on the drive and my workspace was there. I tried rebooting and it was still broken. I threw up my hands and called a friend over to see if he could figure it out. He remembered that Accurev ties source code on a computer to the hostname used when you checked out the code and for some reason my hostname was different. I changed my hostname back and it worked. Accurev wasn't broken. Still, why should I have to care about the mechanics of how Accurev works? It's a problem with Accurev and it leads to engineers blaming Accurev for things that aren't really Accurev's fault but are related to how Accurev forces you to think. So, back to the Accurev visual tool. There's a command-line version of the tool but I'm a visual guy and when working with code I especially want to see what I'm doing. I'm used to thinking of synchronizing all changes I've made in my local version of a project to the code stored on the server including modified files, new files I've added, files I've deleted, etc. Subversion's plugin in Eclipse for example gives me a view that shows me everthing that's different and as a result I quickly learn to trust that I'm dealing with all my changes and not making a mistake. The Accurev tool forces you to deal with different kinds of changes independently. So, I have to perform a search on my local code for all new files I've added. I have to perform another search for all changes I've made and so on. While this doesn't sound like a big deal for me it has been because I have to trust that the tool is going to make it easier to not mess up something as important as source code! This tool doesn't make it easier. So, after all this would I recommend to my company that they change from Accurev to Subversion. No. I love the simplicity of Subversion, how cheap it is and the excellent tools that surround it but for what we're doing Accurev is amazing. We have many engineers working concurrently on the same code adding features planned for releases that are happening all the time. Accurev makes dealing with this overlap a cinch. Sure, we could make it work with Subversion or a host of other source control systems the Accurev folks designed their product to deal specifically with these types of problems. Accurev's first-class citizens are streams not files. Accurev organizes files into streams. Each stream may have a different version of a file. Streams are hierarchical and changes to files upstream can flow automatically down to lower streams. Developers create workspace streams that tie off of a specific stream in the hierarchy. So we can create a top level stream call "release" and from that we can create a separate child stream for each team. Then off the team stream we can create a stream for each point release. Individual developers then create a workspace stream tied to a release they're working on. Accurev's magic is that these streams can be visually re-organized and Accurev will find the differences and where possible deal with merging and moving code. The best part is that it actually WORKS!!!! If we were using Subversion we'd have merge hell over and over from all the different branches of code worked ON concurrently and sure sometimes we do have to merge code with Accurev but think about this - when I'm done workin on version 1.1 of product X I visually drag my stream down to the stream named 1.2 under the stream named X and I'm off and running in the new code. I "populate" my newly moved stream bringing down the differences and I'm done. It's amazing. The other major benefit to this stream-based approach is the process of moving code from development to QA to release is modeled visually in the hierarchy of streams that directly correlate with our methodology. I can go look at all the streams and immediately gain an understanding of the methodology used for creating software. So, Accurev isn't for everyone. Small projects with people working in the same locale should stay away from it. However, if you're working in an environment where engineers are going to be changing the same files and where you have a methodology that requires features release frequently then Accurev is for you despite its pretty serious negative aspects. I just hope they'll improve their visual tool over time. Comments
Be the first to add a comment.
Add a Comment
|
|























