Archive for January, 2008

Vim plugin for AccuRev – 1.0 Release

January 31st, 2008

I’m happy to announce the first gold release of the AccuRev SCM integration for Vim!

For those AccuRev users Vim plugin - File Editingout there that know the true power of the vim editor, life just got even better. Now you can perform over 30 commands directly within vim including keep [\k], promote [\p], update [\u], merge [\m], revert [\rb], diff [\db], status search [\s], and more! The plugin is per-buffer so you can work on multiple files concurrently and perform AccuRev actions on each file Vim plugin - Multiple=independently. In addition, you can work in either console or GUI (gvim) mode! Here are some additional screenshots of the plugin in action.

This vim plugin has its own site at www.vim4accurev.com for downloads, announcements, documentation and user feedback (ala blog style). You can download the plugin from the download page.

The plugin currently requires Vim 7.x and supports AccuRev 4.5.x and the latest 4.6.x. I developed and tested the plugin on both linux (Ubuntu 7.10) and Windows (XP) platforms.

Important note: While the plugin was developed by an AccuRev employee (me) and vim-user for 10+ years, it is considered a third-party open-source plugin and is not officially supported by the folks @ AccuRev support. That being said, I’m proud of the plugin and welcome feedback and enhancement requests for the next release. You’ll find my contact information on the plugin website.

/happy vimming/ – dave

No comments »

Posted in AccuRev, News, SCM Resources

Tags:

Build your own custom interface to AccuRev issue tracking

January 30th, 2008

If I had to guess, I’d say that roughly one third of our customers are using AccuRev’s built-in issue tracking system, called AccuWork. Another third are using one of any number of 3rd party systems, and the last third aren’t linking to issue tracking at all. Those not using issue tracking I feel are missing out on one of the key advantages of software development using an Enterprise class SCM system like AccuRev, but that’s a post for another day. And those using a third party system have that tool’s interface to work with if they want to set up any customizations. So I want to focus on the group using AccuWork.

What many people aren’t aware of is that not only does AccuRev have a full featured command-line interface for SCM operations, it also has CLI operations for the issue tracking as well. Additionally, it has the flexibility of using XML and all the inherent benefits of that language. So an example of what some organizations might want to do is set up an intranet web page where various, non-SCM users can submit issue records without having to go through a specific client application. This can be a very straightforward effort using the AccuWork CLI.

Step one would be to design your web page and forms. Simple for any experienced web developer. Any desired validations and logic would be built into this web page. Step two is to merely grab the form data, translate it into the appropriate XML format, and submit it to AccuRev. Here is a sample xml structure to create an AccuWork issue record (your schema may vary):

<newIssue issueDB="Support">
  <issue>
    <status fid="3">New</status>
    <shortDescription fid="4">We want to have another issue</shortDescription>
    <productType fid="6">Receiver</productType>
    <type fid="7">enhancement</type>
    <submittedBy fid="10">3</submittedBy>
    <assignedTo fid="14">1</assignedTo>
    <foundInRelease fid="20">TP_3.5</foundInRelease>
    <dateSubmitted fid="11">1083606275</dateSubmitted>
  </issue>
</newIssue>

Lastly, you would send this xml to AccuRev using the standard CLI:

“accurev xml -l issueFromWeb.xml”

Bingo, you now have an AccuWork record created! That’s a basic example, but since AccuRev also gives you the ability to query issues and modify existing issues via XML CLI, you can start to imagine the flexibility you have for customization and specialty access.

I’m interested in hearing from development organizations about their issue tracking usage. Do you typically have a wider audience for the issue tracking side than the actual coding side? Does the previous information sound like it’s something you could make use of?

No comments »

Posted in AccuRev, Tips and Tricks

Tags:

scm h00dlums

January 25th, 2008

This week AccuRev had a booth at the Real-Time & Embedded Computing Conference (RTECC) in Santa Clara. The exhibition floor was crammed with circuitry, chips, resistors, PC boards, cables, and apparently the ‘cool’ thing was to have an RJ-45 or USB port directly mounted. The conference was a success as we met current customers, old friends, and folks new to AccuRev, especially firmware developers, who were intrigued with how streams could separate out levels of testing.SCM Humor

Now on to the humor…. Later that day I was leaving a parking lot and spotted a van with a unique marking on the side that was too good to be true. At first, from a distance, I was convinced that the van was the target of high-tech hoodlums from silicon valley. Turned out to be some large stickers.

But I can’t resist… If this were spray paint, the van would definitely have been TAGged!

/happy friday/ – dave

No comments »

Posted in Humor

Tags:

Evil Twins in SCM, Not Hollywood

January 24th, 2008

I keep expecting customers to ask me “Is it contagious Doc?” Or state, “but I am an only child!!!!!” What am I referring to? Evil Twins!!! Sounds menacing right? It really is not, but to a first-time user or someone who has never encountered the warning, “Name already exists in backing stream,” it can be rather perplexing.

So what exactly is an Evil Twin you ask? It is a situation where two completely separate file elements in the same directory structure have the same name. It is actually a common problem across many software configuration management (SCM) systems. So how does this happen exactly? All it takes are two well intended individuals with their own workspaces. Lets use the following scenario, User A and User B both have their own workspaces attached to the same development stream. Currently we have the following directory structure;

\.\dir1\child_dir\

with the following files already under source control:

file_a.txt

file_b.txt

As part of our software project, we also need to create one additional file:

file_c.txt.

User_A creates and adds file_c.txt to source control in the child_dir directory and promotes this newly added file into the development stream.

At the same time, User_A was creating and adding file_c.txt, User_B did the exact same steps. However, A was first to promote so in effect User_A won the race. When User_B attempts to promote his/her file_c.txt the “Name already exists” error pops up front and center and does not allow the promote to continue. Evil Twin prevention at it’s best.

AccuRev tracks an element by its eid (element identification number) and not its name. This is how an Evil Twin is detected. When User_B attempts to promote File_c.txt AccuRev knows that there is already a File_c.txt in the development stream but notices that the eid’s do not match. They are truly separate files since they were independently created and added by different users. They are Evil Twins because they look identical but are different. Really only one of the two is Evil and that is typically the file that ends up getting removed/renamed. But that is another story for another day.

So what should an AccuRev customer do when encountering this problem? Give support@accurev.com a shout and title your email “Need Evil Twin resolution help” or “Name Already exists in backing stream error.” Or you may also take a look at the AccuRev Online FAQ’s in the Customer Support Forum.

Please feel free to let me know if this helps you out!

3 comments »

Posted in Tips and Tricks

Tags:

Eclipse BIRT and AccuRev for Developer Reporting cont'd

January 11th, 2008

In the prior blog on this topic I talked about the types of data I wanted to collect for developer reporting, and the basics I had to do to get the information out of the AccuRev software configuration management tool and into the Eclipse BIRT tool in Eclipse.

I promised charts, but before I get there, I realized I had to do a little more work to massage the data for use with BIRT. When you do an issue query in AccuRev (see prior post) the details for AccuRev users are only exported as the id number. To get this to look nice I ran a second command (accurev show -fx users) to get the user information as xml data. Most AccuRev commands have xml output in the format of <AcResponse>…</AcResponse> so I then ran this result through another xsl parser. My xsl file is straightforward and looks like this:

<?xml version=’1.0′ encoding=’utf-8′ ?>
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” version=”1.0″>
<xsl:output method=”xml”/>

<xsl:template match=”/”>
<users>
<xsl:apply-templates select=”/AcResponse”/>
</users>
</xsl:template>

<xsl:template match=”AcResponse”>
<xsl:apply-templates/>
</xsl:template>

<xsl:template match=”Element”>
<user>
<number>
<xsl:value-of select=”@Number”/>
</number>
<name>
<xsl:value-of select=”@Name”/>
</name>
</user>
</xsl:template>
</xsl:stylesheet>

This generated user tags which I could then use as a lookup when converting the issue data. The output of running this gave me the following xml file (names removed):

<?xml version=”1.0″ encoding=”UTF-8″?><users>
<user><number>1</number><name>…</name></user>
<user><number>2</number><name>…</name></user>
</users>

I could now run the issue xml through another xsl translation, which would use the xml above as a lookup table for user details. The issue xsl I used looks like this:

» Read more: Eclipse BIRT and AccuRev for Developer Reporting cont'd

5 comments »

Posted in AccuRev, Best Practices, Tips and Tricks

Tags:

Streams vs Branches

January 4th, 2008

by Damon Poole

From time to time, people ask, “What is a Stream?” At this point pretty much anybody associated with software development has heard of branches, but streams are a relatively new concept which is similar to, but at a higher level than branches.

Here’s my .02 on streams, coming from the AccuRev point of view. First, I think that at some level the various SCM systems which talk about “streams” are probably all trying to achieve something fairly similar. That is, a “stream of development.”

My initial exposure to “streams” was from hearing folks talk about “streams of development” independent of the SCM system that they were using (which did not have such a concept). The idea was that you had work which was towards a particular purpose, such as new development, maintenance, a team working together on a sub-project, etc. Each of these was a “stream of development.”

I have also heard the terms “codeline,” “development effort,” and “line of development” used in the same context. At the end of the day, the folks which initiate these things (managers, business people, etc) don’t really care how they are implemented, they just want to ask questions like, “How is 4.0 coming along?” and “Are all of the fixes from maintenance in the latest release?” Somebody else then translates that into the appropriate queries, which may be in terms of branches, scripts, streams, or something else.

Prior to AccuRev, I found the need to translate somewhat mystifying. ‘Why should there be any difference between the mental model of “streams” and the implementation model?’

Thus, in AccuRev, the mental model and the implementation model are the same. Streams are the basic building block of the architecture. There are no branches or labels, just streams. There are streams for releases, streams for active development, streams for end users, etc. Each stream except the root stream is defined in terms of a parent stream and inherits everything from the parent (recursively).

So, if you want to do maintenance on the 4.0 release, you would create a new stream based on 4.0 . Through inheritance, it is the same as 4.0. The definition itself is all that is required. The definition is simply “4.0_maint” is everything in “4.0″ plus all of the changes in “4.0_maint.”

Since streams are first class objects, you can act on them directly. You can assign security attributes, lock them, define other streams in terms of them, compare them directly, do queries on them without having to understand how the streams themselves are composed, etc.

For the curious, I’ve written a whitepaper which describes AccuRev’s stream architecture at an even deeper level.

And if you want to go even deeper than that, the basis of AccuRev’s streams is TimeSafe .

1 comment »

Posted in AccuRev

Tags:

Is Defect Tracking Dead in an Agile World?

January 2nd, 2008

by Damon Poole

There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost. The problem of creating a defect inventory is completely orthogonal to the user of a defect tracking system.

A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from an issue tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.

2 comments »

Posted in Agile, Best Practices

Tags: