Archive for January, 2008

« Older Entries
Newer Entries »

Evil Twins in SCM, Not Hollywood

January 24th, 2008 by tim
Share|

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 by jsherwood
Share|

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 damonpoole
Share|

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: