Archive for March, 2008

Fortune 500 Software Company Answers Your Questions on Using AccuRev

March 26th, 2008 by cboran

As one of the world’s largest software companies, we often field a number of questions from people thinking about making the switch to Accurev for software configuration management. I thought I might post some of the common Accurev questions and our answers to them proactively to save a little time :-)


How many users do they have and how big is your repository?
We have 125 users, spanning 3 product offerings, and the repository is about 20Gb.

What kind of storage are you using on the backend?
Nothing too fancy. Windows box with a 100Gb RAID array – mostly done for data redundancy. I think we could have gotten away with less, but we erred on the side of caution.

How fast has your Accurev repository grown since day one?
We have averaged a growth rate of roughly 200-250Mb per year over the past 6 years.

What is the performance of Accurev like?
I can’t say we’ve had many complaints. We have a setup where the primary server is in colocated with the largest US-based team, and we have AccuReplica servers at our other US sites and another at our site in India . My experience is that it is much faster over VPN than Perforce or ClearCase were.

How long did it take for users to become familiar with the streams concept?
Not long at all – hours at most. Our developers caught on right away and loved it. We ran some education sessions to help get things jump started, but most developers understood immediately – “Hey, I don’t have to make the same fix 4 different places anymore!”, and Accurev merging is so good that merge points are no longer a pain for developers.

How many admins do you have?
Zero. We setup some simple policies for behavior – some best practices that we tell everyone, and then my release engineer is in charge of the ‘mainline’ streams that will turn into product releases. It takes him less than an hour a week to do the admin type tasks in the system (update triggers, lock streams on occasion, create user accounts), but by and large the things a ClearCase or CVS admin would do are done by the individual developers. Our developers love it because it empowers them to do what they need to do.

What kind of response speed do you get from Accurev support?
Accurev’s email-based support is excellent. I can’t recall ever waiting more than an hour or two for someone to answer, and usually it takes only 1-2 emails to resolve the problem – the support team knows that they are doing. In 6 years I can’t recall EVER having to pickup the phone and call the support line because the email is answered so quickly.

How painful are server and client upgrades?
They are a piece of cake. The regular installer is smart enough to perform the upgrade in a wizard fashion and there are no skill testing questions! When we went to v4.6 it took less than an hour to perform the upgrade, push new clients and verify that everything was working, including our build system. If you have provisioning software you could deploy the new clients in moments. We have upgraded our servers all the way from v3.0 and have never experienced any issues at all with the upgrades.

What do you like least about Accurev?
Directory scanning can be more time consuming than I’d like. It would be nice if it were done as a background task all the time when the UI is running instead of only when you make a request. Other than that, I’m hard pressed to think of anything I don’t like.

What is the best thing about Accurev?
Developer Empowerment – far and away this tool lets my developers do what they need to do exactly when they need to do it.

Parrallel development – never have I worked on projects that required so little codeline coordination as we’ve enjoyed since taking on Accurev. Merging code is so easy that merge points are done in a fraction of the time. And Accurev makes it possible to merge your code so often that merges are less painful when they happen.

Visualization of change – with the dynamic process version browser and the annotation tool visualizing how your code has changed over time is a snap.

Continuous Integration: Building the Pyramid

March 13th, 2008 by jsherwood

I just saw the movie 10,000 B.C. (No, not the movie about when ClearCase was created). Certainly a diversion from everyday tasks, but I found myself focused on a couple of aspects of the movie. My first reaction seeing the workers moving the stones to build the pyramids (never mind the accuracy, just stay with me) was: how long does it take to move a single stone up that ramp? What if it took the group of workers pulling it a whole day? And what happens if they pull it all the way to the top and it cracks? Or is the wrong size? Now you’ve got to get rid of the stone and you lost a day.

Now take a look at the developers around you. You’ve labored hard all day, you feel pretty good about your accomplishments, take a rest and review it tomorrow. But you come in the next day and the build failed. You hauled that code to right place, only to find it cracked and the wrong size. What have you got now? You lost a day, your workers are all pointing the finger at each other and management wants to know why there’s a delay. You’re now spending the second day figuring out what was wrong on the first day, delaying the work you should have done.

Sounds pretty bad right? What you need is a way to continuously check what is going on. So you ask each developer to run a build, maybe even run some tests before promoting their code. Each developer seems to be on track, but now those integration points keep burning you. Bob only thinks in Windows, he keeps making references that work on his machine. When Julie, your UNIX guru, gets them they never build. Now you need some integration checking. But if Bob performs the integration on Windows he doesn’t have a problem (today) and Julie is sick and tired of managing Bob’s work. The build guru you hired would mutiny if she had to run builds all the time. You need some automation to relieve the pain.

And along comes Continuous Integration (CI). Martin Fowler wrote a great summary of CI (you can find the materials here). Besides this article there are many tools and even some books that are worthwhile for in depth knowledge of CI (take a look at Continuous Integration: Improving Software Quality and Reducing Risk – a 2008 Jolt Award winner). I’ll do them all a disservice and sum it up: frequently integrate autonomously.

I find the keyword here is autonomously. I don’t understand why developers spend so much time writing software for others to improve their processes, and yet they are willing to manually and repetitively do their own work. And to top it off they will rewrite software over and over. Just as you shouldn’t be spending your time writing a file i/o subsystem for the umpteenth time, you shouldn’t be running your build processes manually for the umpteenth time. If you can spend 2% of your time integrating builds instead of 15% of your time, isn’t that better?

Some time ago we had the problem I described above with Bob and Julie. We had Windows developers whose code would prevent builds on occasion with another OS. We have six primary OS that we ship, with many other variants. You can imagine the pain when nearing a release date, if you were to come into the office and find out you have no build. Once this happens it becomes a midday manual process to run and test the build. What drudgery. CruiseControl can solve this problem, and with a little work, can run with your custom build scripts. CruiseControl can greatly reduce the loss of nightly builds, as a matter of fact I’m hard pressed to think of the last time a nightly build failed for this reason, although we’re looking into commercial offerings that provide even more value. For now, having developers speak up (Hey Joe, that checkin you just did failed on Linux) can reduce your own personal stress level. You’ll have less hesitation to check in code just before you go home, with less need for connecting the dots because CI has your back. On occasion driving home my phone still buzzes, and when it does I know the build failed. Not the nightly build, CI alerted us soon enough so I still have time to fix it before that.

No worries. We’ll get that pyramid done on time.

AccuRev admin tricks – SCM law enforcement

March 12th, 2008 by jtalbott

Here’s an AccuRev Tech Tip you might not have been aware of to help with your software configuration management law enforcement. As you know, the AccuRev TimeSafe architecture guarantees that every single transaction ever executed is going to be fully traceable, a blessing to those who care about auditing, perhaps regulatory compliance, or even just wanting to be able to see who has been up to what.

But what if you want to know what has *not* been done? Huh? What the heck am I talking about? I’m actually referring to commands that are not executed because you’ve put security in place to prevent them. So even though the offending users don’t get their way, perhaps someone might want to know who is trying to upset the apple cart or merely have the ability to apprise the user of organizational best practices.

One way to do this is through email. Let’s say you’re implementing the default set of commands that AccuRev limits to Administrative users, and someone unauthorized tries to create a new user. Put the following into the proper place in the server_admin_trig trigger:


  if ( `$::AccuRev ismember $principal "$admingrp"` == 0 ) {
       print TIO "Execution of '$command' disallowed:\n";
       print TIO "You are not in the $admingrp group.\n";
       system("simple_email", $arg1, $arg2);  # insert this line #
       close TIO;
       exit(1);
  }

Now, whenever someone who isn’t allowed tries to create a user, you can get a nice email that says:

To: anyone_who_cares
Subject: AccuRev alert
Body: User “jtalbott” tried to run the “mkuser” command. That’s 10 demerits. Put him on double-secret probation!

…or something similarly amusing. What you’re basically doing is sending your desired parameters into the simple_email script. You can write your simple_email script using whatever language you want, as long as it’s accessible in the local path, and naturally it would be reusable. Now, for virtually any operation in AccuRev that you want to know about, whether you want to know if it succeeds or fails, you can get notified about it. You’re certainly not limited to email either. simple_email could send text messages, page someone, basically any form of communication you prefer that can be coded.

It really is that easy. I highlighted a certain example, but there are many practical applications. How do you think you would be able to take advantage of this in your organization? Or if you’re already doing it, what kind of things are you communicating?