Leadership

AccuRev offers advanced version control for Agile development

Justin James recently spoke with AccuRev's CTO about the company's version control system. If you're working on a large or distributed team, AccuRev's flagship product may be for you.

 

After writing about Rally Software (which makes software for managing Agile projects), I was introduced to a partner of Rally's named AccuRev. I recently had the chance to talk to Damon Poole, the CTO of AccuRev, and learn a bit about the company's products and what they do.

In recent years, AccuRev shifted its focus to Agile development. It specializes in visualization and enforcement of software development processes. The general idea of AccuRev's products is not to be "heavy handed" but to function instead as a "helping hand." AccuRev's software aims to take the thinking out of following the rules and processes put into place.

Damon said that AccuRev's typical customers are "people where the software is mission critical to them," not shops where coding is a "seat of the pants" process. Its customers range in size and not all of them use Agile.

Multistage continuous integration

One topic that Damon and I discussed is the concept of continuous integration. In Agile development, as each person develops, their work is "continuously integrated" into the main code tree so the other developers are immediately using it too. This works well on smaller teams, but on larger teams, it devolves into chaos. Damon calls it "continuous noise."

Although I have not worked in an environment where this was occurring, I can definitely imagine the difficulty of trying to work while also trying to constantly deal with code breakages due to the constant integrations. To relieve this pain, AccuRev enables "multistage continuous integration" (MCI). MCI breaks the overall team up into a "team of teams," and each team performs its own continuous integrations and then periodically syncs with the main code branch. This allows problems to only cause the relevant team to resolve them, instead of having them impact everyone.

Version control system

The company's flagship product (which is called AccuRev) is a version control system that also contains process management. This is where the MCI system gets implemented. In talking to Damon about AccuRev's version control, it sounds like a system that is very nice to use.

It is an object-oriented system, where each node of the version control can do things like inherit from a parent. AccuRev's system allows the developer to literally see the branching of the code. Because of the object-oriented node structure, you can do code merges quite easily.

Damon also talked about a feature that I find neat; it's the ability to select multiple nodes and perform analysis and selective merging, such as, "show me what bug fixes are in node A and not node B" or "merge only the bug fixes from node A to node B, but not the new features." You can also pick any given node, and see a complete view of the product as it exists at that node. This is pretty powerful functionality. AccuRev's system has an integration engine that allows its products to easily integrate with other systems (including Rally), various build tools, and a number of bug tracking systems.

Useful for specific teams

Based on the features I discussed with Damon, AccuRev does a lot more than most of the version control systems that I've seen. I think its system is very good, particularly for large or distributed teams. AccuRev may be overkill for some developers, but for environments where a strict adherence to a particular process is needed, a system like this could definitely be useful. (The company offers a 30-day trial of AccuRev.)

I would definitely like to hear from anyone who has used AccuRev. If you have, please post your thoughts about the company's products in the discussion forum.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

-------------------------------------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

7 comments
Jaqui
Jaqui

why such an ancient kernel in their NEWEST version? [ my own kernel version is 2.6.24, and is several versions BEHIND the actual current release. ] are they one of these companies who insist on using badly outdated linux distro versions? ahh, nope, they do support newer kernels. to bad they insist on making a tool that is kernel version dependent though. neither cvs or subversion are dependent on kernel version to that extent. [ they will build on kernel 2.4 or newer, not 2.4.9 or newer. ] Other than the typical insanity of the proprietary software company in coding to drive open source users AWAY from their products it looks like it is a good tool set.

Justin James
Justin James

One thing that I found interesting about AccuRev, is the idea that version control can act as a partner in your development process, and not just as a complex file system. How does version control fit into your development process? J.Ja

damon
damon

Hi Jaqui, Thank you for the kind words on our toolset. Regarding the issue of the kernel version, our source code is not dependent on a kernel version. But, we don't distribute source code. Our customers want binary distributions that have been officially QA'd and are a known quantity. They also want to just do an installation and not have to do any coding, building, tweaking or worrying about environmental issues. To meet these requirements we need to create a binary distribution, and that means building on a machine and that means picking a minimum required version. We move the minimum up from time to time because newer versions are generally simpler for us to support which means we can provide better support to our customers. Cheers! Damon

aidenandabetting
aidenandabetting

Glad you realized that the kernel requirement was a *greater than or equal to* one not an *equals* one. But since you bring up the point of proprietary vendors coding away from open source users, what open source user worth their keyboard is on a linux distro with a kernel prior to 2.4.9? I think *ancient* was the term you used! I do however agree that you want to support the software development community at large without placing artificial barriers to usage in the way, but I think there is a lot of leeway here. Otherwise you'll have the Commodor 64 and Atari enthusiasts clamoring for support ;-)

chris_boran
chris_boran

I worked with Accurev for the last 6 years. If I can say only one thing about what I like about Accurev it is empowerment. It is a system that makes tasks so easy to perform that developers can be free to do what they feel is best. If I want my feature to work off your feature, I just move my stream under yours. If three of us want to work on the same codebase and share as a team, we create our own project stream. If I want to jump between three projects, I can just drag my workspace around. The flexibility and simplicity of control is so great that you don't have to worry. Using Accurev made planned merge points on the schedule a thing of the past. With it's great file support (where identity of a file isn't its path name) enabled us to be free to refactor at all, changing file names without needing to worry about consequences - something that I've seen cause problems with other SCM tools. By tying together your bug tracking and source control, you have the power of being able to move bug fixes as atomic units - no half-way 'merge problems' show up to bite you. With its great version browser and annotation features you can know who introduced what change when. In short, I found that it simplified our development processes by empowering the developers to make their own decisions and by giving them the tools to make their lives easy.

Jaqui
Jaqui

I get leary with most proprietary packages available for linux is mentioned: http://techrepublic.com.com/5208-12845-0.html?forumID=102&threadID=274498&messageID=2602034 it boils down to $1,000.00 US for software that is not functional on current distros 18 months after release date. personally, I do prefer to install from sources [ I know, I'm wierd ] so that I know the software will run properly. I've spent days doing installs to see exactly where Kylix fails with newer kernel versions and have a distate for the whole binary release model from it. I know, open source model isn't an attractive one for most software houses, and the GNU-GPL is the worst license for getting commercial software houses to support open source operating systems. I was actually pleasantly suprised that you supported GNU-Linux at all because of that.

Jaqui
Jaqui

was things like the "no longer in production" Borland Kylix IDE, built to [b]require[/b] the 2.2 kernel, though it would still function on a 2.4 kernel system. or Corel's short lived CorelDRAW! Suit for linux, also [b]required[/b] the 2.2 kernel. I still have a system running a distro from 1999 to be able to use both those apps. can't take it online, since there are no updates for the distro any more, the current browsers won't install so can't access any websites with it. [ kernel 2.4.24 on it, newest distro to run the apps. ] by locking it to ANY kernel verson other than the [b]current[/b] or newer, you drive open source clients away. "but I think there is a lot of leeway here. Otherwise you'll have the Commodor 64 and Atari enthusiasts clamoring for support" GNU-Linux runs on i386 with 32mb ram, that is the minimum hardware, if your app requires more, it needs rewriting. :p [ the linux kernel now requires more, but it still supports running on i386 with 32 mb ram, it just won't build on it. ]

Editor's Picks