Our Agile Comes to You seminar tour with AnthillPro and Rally is starting to wind down, with only 1 more seminar to go in this round!  (Check out our events page for more information.)   It’s been a very successful tour thus far, we have answered a lot of your questions about Agile adoption and Agile pain points, worked with some great presenters, and met a lot of Agile enthusiasts.

Check out what attendees are saying about Agile Comes to You, read a presenter’s point of view about a recent seminar, or follow #Agile2U on Twitter.

Agile Comes to You is brought to you by:



Missed the seminars?  Here are a few more events you might be interested in: http://www.accurev.com/events.html

If you are having trouble convincing your CFO to spend money on capital expenditures in this challenging environment, you are not alone.  Forecasters are projecting a significant decrease in capital spending for 2009, which is making buying new software and hardware very difficult to get approved by senior finance executives.

So how does a software development manager convince a CFO to spend money on new software and equipment?  CFO’s are seeking ways to increase the efficiency of how organizations deploy resources as well as how to control costs.  So focus on the Return on Investment (ROI), or net cost savings from the increased efficiencies, when you try to convince your CFO to approve a purchase.

The following is an example in which a company is determining whether to hire a new engineer or buy new software and hardware for the team whose productivity needs to increase 20%:

Assumptions

• Cost of software and hardware to be acquired – $50,000
• Size of team – 5 engineers
• Increased productivity from acquisition – 20%
• Average fully loaded cost of an engineer – $125,000

Cost Benefit or ROI

Based on the assumptions above, if the team were to increase its productivity by 20% without purchasing new software or hardware, they would need to add one engineer (20% x 5 engineers) at a fully loaded annual cost of $125,000.  Accordingly, if it is expected that the workload of the team is going to increase by 20%, it becomes an easy decision: spend $50,000 on new software and hardware instead of hiring a new engineer at a cost of $125,000, for a net cost savings of $75,000.

The typical CFO is also likely to question whether demands on the QA team will really increase and when the timing for the purchase of new equipment has to be made.  When this question comes up, and it will, you can now argue that if demand actually stays the same or decreases, you will be in a position where you can reduce headcount by 20% (a savings of $125,000) without losing any capacity.  This is the beauty of focusing on the efficiencies created from deploying new software and hardware

Summary

Engineering budgets are dominated by personnel costs.  If you focus on the efficiencies that will be created from deploying new software and hardware and tie it to either being able to cut headcount or not having to hire new staff, you will almost always be able to convince your CFO to open up the purse strings!

About The Author

Peter Dreifus was invited to contribute to our Distinguished Lecturer Series because of his experience as a CFO and COO managing finance and operations at software and technology companies.  Mr. Dreifus is a CPA with over 20 years experience and has held a variety of senior finance positions at Escher Group, Ltd.,  Sequence Design, Inc., Avery Dennison Corporation and the accounting, tax and consulting firm Deloitte.

In May of 2005, the company I worked for, Polycom, decided to switch our Software Configuration Management tool from ClearCase to AccuRev. Initially, this decision was not taken well by the developers in my business unit since they had been using Base ClearCase for several years.  However, after seeing how much easier AccuRev was to use and that it did everything that we needed for our development tasks, we became firm believers that AccuRev really is a “Best of breed” Configuration Management tool.

We evaluated a couple of CM tools before settling on AccuRev.  Among the tools we looked at were IBM Rational ClearCase UCM (which I was very familiar with), CVS, and Accurev.  CVS was being used by development teams in both offices and it was determined to be a tool that would not scale well for us.  After evaluating ClearCase UCM and AccuRev, it was decided that AccuRev was the way to go, for several reasons.  One reason Clearcase UCM did not do well was that we could not even get it to work at one of our offices that was using Linux for development (they were using 9 different types of Linux at the time).  AccuRev positively shined during this part of the evaluation by the fact that it was very easy to setup and use in a Linux environment.  Another reason and a huge advantage for AccuRev was the fact that it was very easy to use over a WAN between multiple sites (i.e., Austin TX and Andover, MA) without a mechanism like MultiSite.  The AccuRev servers that the development team in Andover used were located in Austin, TX.  For the 3 years that that I worked with our team using AccuRev, I never had any major issues using it over the network.  A third big reason was that we also did not have to pay for ClearCase MultiSite licenses which meant a big cost savings for the company.  This last reason was major factor in management choosing AccuRev over ClearCase UCM.

After selecting AccuRev as our new CM tool, we had to migrate the current source code that was in ClearCase. At the time that we were doing this, there was no migration tool to take source code in ClearCase and move it over to AccuRev. We decided to archive the existing ClearCase Version Object Bases (VOBs) and leave them as is on their current servers in the Andover, MA office.  This was determined by our management team to be the best way to start off using AccuRev.  Most of this legacy code was for really old products that had been “End of Lifed”.  So, we were not really losing much by doing this.  We then imported the latest code from the VOBs that we cared about.  The import of this source code was just brought in as flat files.   This worked out well for us and for those who wanted to keep legacy history around.

The training for using AccuRev was very short.  AccuRev sent a trainer to our office in Andover and we had 2 groups of developers (about 15 each), attend a training session that was less than 3 hours long.  One half day of training for the developers.  It was that simple.  After this training, I was available to help the user community with any questions that they had.  I do have to say, I did not spend much time at all helping fix issues related to AccuRev.  For any issues that did come up and I couldn’t help out with immediately, AccuRev Technical Support was always there to help.  For the record, I did not attend any special AccuRev Administrators Training.  AccuRev does have AccuRev Certified Engineer Training available and that was something I wanted to take.  Actually, whatever administration was needed for AccuRev took place in the Austin, TX office.  The person who did that did it a part time basis.  This is also much different than ClearCase.  I have been a full time ClearCase Administrator at several companies and that is a full time job.  When I was working with ClearCase, at least 20 and up to 30 percent of my time was spent on administrative tasks related to ClearCase.  So, I was able to devote that extra time to work on other types of things, like the install kits for our products using InstallShield.  We had been considering hiring a consultant to do that work and we ended up saving the money that we would have spent on that.

After the import was done, developers were able to create projects and streams very easily. It did take a little while for everyone to get used to the concept of projects and streams.  I had used ClearCase UCM in the past.  So, I had no problem relating to these concepts.  For the rest of the development team, the concepts of projects and streams was very easy to get used to and made a lot of sense to them.   There was a slight learning curve for the developers with using some of the AccuRev utilities like the Version Tree Browser which looked different than the one that they were used to in ClearCase.  There were some concerns about using the AccuRev Merge Tool.  However, I attributed that to the fact that the developers may not have completely mastered the concept of merging in ClearCase, since to me it appeared to me much easier to merge source code in AccuRev than in ClearCase. The ability of the development team to quickly grasp the concepts of AccuRev saved a lot of time that would have been spent training them.  I literally was able to sit with new people on the development team and within a half hour, they were up and running with AccuRev.

Overall, I think that our use of AccuRev made our source code management much easier.  The ability to use the Graphical User Interface for most of our work was very beneficial to us. It was great to be able to create streams (or even projects) based off of a particular stream and to be able to literally see that being done on the screen, for example.  The snapshot concept also worked well for us.  It was also very easy to find the differences between build snapshots.  This helped us produce metrics for management very quickly.  We also had no issues implementing AccuRev commands into our build scripts which made our job easier.  Before we used AccuRev, we would run the builds and access CVS databases in the Austin office.  The builds had to be run at night because the builds took so long copying the code over the WAN from Austin to Andover.  After switching over to AccuRev, the fact that we could access the the AccuRev repositories in Austin directly over the WAN allowed the builds to complete much quicker than when we were doing them using CVS.  We never figured out why the copy of the CVS code took so long, but I can tell you that after switching to AccuRev, the build performance improved at least 25 to 30 percent. We could even run them during the daytime when needed, which was very beneficial to our development team.

As I mentioned above,  AccuRev Technical Support was very helpful with any questions or concerns that we had and I can never say enough good things about them.  AccuRev Tech Support always answered their phone quickly and followed up with us on anything we worked with them on.  Based on my 3 years of experience of using AccuRev, I would highly recommend it to development teams that are deciding on a Source Code Management tool.

I work for a large software company, and we’ve used AccuRev to facilitate using a large scale distributed Continuous Integration model.

AccuRev makes this possible with the Stream approach to managing different codebases.  Developers run builds using the same build scripts used by the core team for production builds that ultimately are packaged and shipped out of Engineering.

These build scripts not only build and package and kit the product, they also run thousands of xUnit tests written to run fast and fail fast.  Developers that encounter failures immediately know where to fix the code to pass the tests.  We also use test driven development.

Each day, developers promote their changes to a task stream.  We use Scrum, so a task stream correlates in most cases to a Scrum team.  This team runs automated builds / tests at their task stream level and when stories are done and accepted and passing, promote the appropriate changes to the integration stream.

The integration stream is built every afternoon, and any test failures run during the build are quickly addressed by the team.  Our Continuous Integration software provides a failure email with the modifications made that day with AccuRev user names.  Developers can then go into AccuRev using the StreamBrowser and the Version Browser and determine the root cause.

Fixes are then promoted back to the integration stream, and the full nightly build in most cases runs successfully.  We fail all integration builds on test failure as we believe in Continuous Integration.

Each week our qa level stream is built and we repeat the same process. Developers handle the promotes, the central release team does not promote code for teams.  As code promotes up the hierarchy from task to integration to qa the frequency of broken builds, due to test errors or compilation, decreases.

This Multi-stage Continuous Integration approach is easy with AccuRev due to stream inheritence.  If you used a branch / merge solution you would need to staff a central team just to manage the commits to source control, and manage code that is “done”.

I work for a large global enterprise software company with over 500 users, that has been using AccuRev for over 4 years.

We are currently managing a Beta release of our main product line.  The management of the source code is easy thanks to AccuRev, and here’s why:

1) Stream inheritance is just plain awesome!

We manage hundreds of streams to make up our suite.  We are able to promote code up through task streams, to integration streams, to qa streams where we ship.  For the Beta, we have child streams qa.beta, and our build machines use these streams.

2) Snapshots rule!

Snapshots by definition are immutable.  So you know what you built, when you built it.  Our build process creates snapshots automatically, and we fetch code based on snapshot.  We have 100% confidence in knowing what went into a build, and our snapshots are named to a pattern i.e. <parent stream>.yyyymmddhhmmss.build<build number>.  That gives one a lot of info about a build.

3) Timelocks let you stabilize code, even if set the next day!

We built our Beta release on snapshot, and the next day we retroactively set time locks on the qa.beta streams based on build time, and we access locked them down.  Now we can finalize the Beta, and still allow other integration and qa work to happen.

In summary, if we were using a traditional branch/merge SCM, this would be a lot of work and require dedicated personnel.  Instead, we did this part time and the StreamBrowser makes is so easy to see what code is where and why.  There is no confusion with views or other techniques used by other vendors.

By Ryan LaNeve, AVI-SPL

Much has been written on this blog already regarding the ease with which AccuRev allows you to tailor your development process without having to fight with your SCM software. While I could offer yet another account of how simple and straightforward it is to manage our particular process using AccuRev, instead I thought I’d take a few minutes to point out some of the things we’ve done using the tool’s command-line interface and its ability to output results formatted as XML.

Of the various tools we have created over the years, the two we find most useful are what we call “AccuLoad” and “SQL Object Scripter”. The former pulls data out of AccuRev, while the latter puts data into AccuRev. Both were developed in a matter of hours thanks to the extremely intuitive command-line interface which AccuRev provides. Let’s take a closer look at each.

We’ll start with our “SQL Object Scripter”. Anyone whose development efforts involve a database server knows how difficult it is to maintain change logs for the “code” kept within the database. There are a number of “best practices” with regards to maintaining this information within an SCM, but in our experience they are all too time-consuming and involved, which leads to one or more members of the team either forgoing the process due to time constraints or just ignoring the process all together. Maybe we’ve just become spoiled by AccuRev allowing us to work exactly the way we want and otherwise staying out of our way, but we now have a hard time following any procedure which requires us to change the way we do things.

So one day a couple of us sat down and decided to find a new solution. We felt that, at a minimum, what we really wanted was to be able to view changes over time for our database objects, such as tables, views and stored procedures. We knew that if we could just get each change into AccuRev some of our issues would immediately disappear, but we found it too difficult to require the entire team to manually create every script and then manually promote that script into our SCM. We decided that what we needed was a tool that could simply detect changes to our database objects and automatically store those changes within AccuRev. Again, thanks to the simplicity of AccuRev and its CLI, our “SQL Object Scripter” tool was born in a matter of hours. We now have a record in AccuRev of (almost) every change made to any database object we care about, which then allows to use the features of AccuRev to view the history of any object, the differences between any versions of any object and even an annotation of any object to see who is responsible for the make-up of the object. The solution consists of a few parts: a SQL Server table to store DDL change event details, with a DDL trigger on the various databases we care about. The trigger fires whenever a DDL event occurs, such as the creation or alteration of a table, view or stored procedure, and the details of the event get logged to a table. Our custom console app is then scheduled to run every few minutes and checks the table for any records. When a record is found, the console app scripts out the definition of the object to a file and then uses the AccuRev CLI to add/keep/promote the file to our “SQL Scripts” depot – whatever is appropriate depending on whether the object is brand new or pre-existing and has been changed. The AccuRev commands all run within the context of whichever user made the change in the database itself, so all of our AccuRev transactions are associated with the correct team member. While this solution is not optimal and does not provide as much traceability as having each developer maintain and promote database change scripts themselves, we have found it to be an excellent interim solution which was extremely easy to put together.

Another of our tools is the one we call “AccuLoad”. The purpose of this tool is to pull various bits of information out of AccuRev and load that information into a database. We then use the information in the database from several other applications. The tool is a console application which runs in a couple of different modes, but the primary mode is run via an AccuRev trigger. Whenever a promote happens in one of our depots, our custom trigger runs and fires up our console app, passing in a few details such as the name of the depot, the name of the stream and the transaction number of the promote. AccuLoad then takes this information and makes various calls to the AccuRev CLI to gather more details, such as which elements were included in the promote, the version numbers of each of those elements, the user who performed the promote, etc, etc… Additionally, a diff is run against any changed elements, and those details are stored in the database as well. Gathering all of this information from AccuRev was extremely simple thanks not only to the intuitive nature of the functionality exposed by the AccuRev CLI, but also thanks to the option of having the results returned as XML. While I’m sure it would have been possible to create such a tool using any SCM, I doubt we would have ever found the time to do so had we not been fortunate enough to have AccuRev as our SCM. It was, again, only a matter of hours from the time we came up with the idea for AccuLoad and the time our first promotions were being logged in our database.

Having this database detailing the activity in our SCM, we were then able to create several other tools to utilize the information, such as one we call “AccuBrowse”, seen below. This web-based application allows us to browse the database and view any transaction within any stream of any of our depots, and see who performed the promote, the comments supplied during the promote, the elements included in the promote and the differences for any changed element. I should mention that much of this functionality is probably available in the AccuRev Web Interface, though we have not actually used that tool provided by AccuRev. Ours was created a couple of years ago and suits our needs. Beyond just allowing us to browse our SCM history via a web-interface, our database also allows us to perform some analysis, such as frequency of change for elements within a specific depot or stream, which allows to keep tabs on classes within our systems which may have too much responsibility. We can even run queries against the data to find “problematic” code, such as those files most often included in promotions which cause a failed build (not that our builds ever fail, of course…).

In summary, there are a myriad of fantastic features and functionality within AccuRev which make it a great fit as an SCM for any development environment. Once you’ve got your core needs taken care of by the out-of-the-box functionality, I encourage you to explore what can be done with the provided CLI and its XML-formatted output. In our experience, if you can imagine it, you can build it with AccuRev in no time at all.

Our custom AccuBrowse application, viewing a transaction involving a SQL Server stored procedure:

by Chris Boran

Several years ago I happened to be browsing in my favourite local bookstore and one book in particular caught my eye: Martin Fowler’s Refactoring: Improving the Design of Existing Code

This is the book that changed my whole career. Up until that point, I had lived in a constant state of fear of change. I viewed old code as a house of cards – if I wasn’t very careful, it was all going to come down around me. Whenever my boss asked me for advice about what to do in a given area of the code, my answers were almost always similar to:

The risk of doing anything but the smallest possible change is huge – so either we do something that is an ugly hack that we will regret later, or we need to take the whole thing apart and re-implement the whole subsystem from the ground up.

And predictably, my boss’s answer was always something like:

Okay, we will live with the hack for now, but in the next release we will make time to do it right.

Of course every release we were forced to make many similar decisions. When the next release would come, the newly conceived product features would get priority over fixing code that was already working passably. In practice we might get lucky and be able to spend lots of time rewriting a single small subsystem, but introduce ugly hacks that would put 4 other systems on the map for future re-implementation.

The end result is affectionately referred to as a Big Ball of Mud. Yup, it is every bit as pleasant as it sounds. Life is just so miserable when you come to work every day knowing you are going to have to pack another layer of mud on the ball. You gripe about it. Your teammates gripe about it. Your boss gripes about it. Somehow you never seem to make a whole lot of forward progress.

As I read the book, I was at first skeptical. I thought that bad old code needed to be thrown away and not revitalized! But I wanted to see if it would work, and so I set out to try it. I was very careful to follow the techniques exactly as they are laid out in the book. I made sure not to use the word refactor when I really meant rewrite. I was careful to refactor the code every time I saw something I wanted to change and not just note it for later. I made sure that my refactorings were small. I took my time with it.

Obviously working this way required that I also be doing very good unit testing, but I had already bought into Test Driven Development. I was already writing unit tests for code before fixing bugs in an attempt to prevent regressions. Running these tests after each refactoring was not a big challenge for me.

Bit by bit I discovered the truth. By applying the refactoring techniques, I could take pieces that I thought needed to completely rewriten and make them better while I was fixing bugs in that area. I could kill two birds with one stone.

Then I discovered Eclipse. The built-in refactoring browser captivated me. Suddenly there was a good, fool proof way to do many of the common refactorings, and automation to keep them introducing new errors. My commitment to refactoring was completed and the defect rates in the code that I was responsible for maintaining declined dramatically. I was a convert. Since that time refactoring has been a cornerstone technique in my arsenal. I no longer lived in fear and loathing of old code!

One refactoring that I have still found to be painful, despite Eclipse’s facilities, is renaming files/classes. In most software configuration management (SCM) tools, renaming files can have unfortunate unintended side effects because the identity of a file is its path. This leads to a great many developers to name a class once, and then never change its name – even if that name does not make sense and the design of the code and the classes primary purpose and responsibilities change.

Luckily for me, I am a long time Accurev user. In Accurev, files are not identified by their pathnames, but rather by a unique id. This makes it possible to quickly and easily rename files with no negative side effect. However this process was inconvenient – I would have to drop out of Eclipse, rename the file with Accurev’s tools, and then refresh my workspace. Not ideal, but it worked. That is why I was so pleased when the Accurev-Eclipse Plugin was released – it integrated the Eclipse Refactoring browser’s rename actions with Accurev’s capabilities to make the whole experience seemless. Accurev has helped me to maintain well thought out, easy to understand designs despite constant evolution to those designs.

by Tahir Hussein, Alterian

This diagram shows one key aspect of our development process i.e. 3^rd Line Support. It is critical to our operations because we support anywhere from the last 3 to 5 release steams. This includes monthly patch releases which address key customer defects and enhancements.

3rd Line Support

Prior to 2006 our development operation was UK based (in a single location). Everything was straight forward! However, when we opened up a development centre in Bangalore, that situation changed. Once we had recruited and trained the developers it was time to get them using our SCM tool, Serena Dimensions. This has served us well since 2000 but the performance of the connection to Bangalore meant that the PC and Web clients were totally unusable for shared development work e.g.

* It was taking over 5 minutes for them to browse change documents

* Editing the attributes e.g. to specify the fix times etc was taking around 10 minutes

* Making any kind of source code changes on a change document, especially one with a lot of additional related items or change documents was even longer.

* To fetch all 9000 items from the repository for a sandbox development and build was an overnight job (if it worked at all!)

Hence we had to put our thinking caps on and come up with another solution.

We tried making use of Subversion and associated tools and initially this looked very promising. However, when we started putting our Development processes on top of Subversion, in particular “Branching and Merging”, it became apparent that the underlying SVN functionality was not going to be mature enough for the tools to be available to cater for this. The solution we were looking at was Subversion running in UK and Bangalore, with the replication of data taken care of by a product called WANdisco and the Application Lifecycle management by Polarion. We had a number of meetings and discussions with all of the above parties, including the Subversion developers, who gave us an insight into the future plans. In the end the overall solution was not going to be elegant and satisfy all our needs. We carried on looking and eventually came across AccuRev.

At first we were reticent to go down this route as it was a proprietary system. However, when we were demoed the system by the AccuRev guys it seemed to fit in exactly with what we were looking for. Even with the addition of merge tracking in SVN, AccuRev is still head and shoulders above with its merge, change and namespace tracking.

We then obtained a demo license and spent a month evaluating the product against our list of requirements. The sort of checks we carried out were:

* How long does it take to create something e.g. stream, workspace in the UK and see it reflected in Bangalore and vice versa

* Can you create/delete hundreds or steams without affecting the system performance

* The critical one of can a number of developers on the UK and Bangalore work together on a set of changes in parallel and easily have those merged back together.

The whole thing ran so smoothly that we could no longer delay the decision to purchase. Last year around this time we purchased the required licences and then started the process of moving the development over to AccuRev.

So, where are we currently?

The intention has been to move over to using AccuRev and Jira combination (as Serena Dimensions covers both Issue Tracking and Source Control). However, as we have a limited number of resources available, and the fact that we require quite a lot of work to implement the appropriate workflow and associated build process, we have not had the time to do this. We are currently using AccuRev for ALL development and 3^rd Line support work but still use Dimensions for the Issue tracking and build process. Given that none of the developers in Bangalore or UK are impacted by this and can get on with their day-day work then I am cool with this. The only person affected is me as I have an additional step to perform by moving changes between AccuRev and Dimensions and vice-versa. I am confident that in the near future we will fully move onto the AccuRev/JIRA system and gain even more benefits.

I hope this will be of help to others and I would be more than happy to answer specific queries.

By Tomas Lundström, ReadSoft

A consistent naming scheme makes your life easier and is also a good way of avoiding name clashes in AccuRev. Here follows my stab at it. (With one important disclaimer; for multi-depot installations, you should use a depot prefix for all streams, to avoid name clashes between depots)

AccuRev Codelines and Baselines

The following naming rules apply:

• Character set. For scripting compatibility, allowed characters are English alphanumericals, underscore ‘_’, hyphen ‘-’ and period ‘.’.
  In particular, blanks, Swedish characters and slashes are disallowed.
• Case. Product names and keywords exclusively use ALL UPPER CASE, other text and component names use mixed case.
  Examples:APPROVE_REL, Libraries_DEV
• Main codeline streams: <CODELINE>_<LEVEL>
  Examples: APPROVE_REL, DOCUMENTS_DEV
  In the basic case, there are two (optionally three) levels of streams for a codeline:
  • REL. Release stream, where final main releases of products are done.
  • QA. QA stream (optional). If not present, the REL Stream serves QA as well
  • DEV. Development stream where developers share code, and perform initial integration.
    
• Maintenance codeline streams (‘branches’): <CODELINE>_<VERSION>_<LEVEL>
  Examples: APPROVE_5-1_REL, DOCUMENTS_6-3_DEV
  Maintenance codelines may be single level, in which case it shall have the level REL, or it can be two or three levels, just like a main codeline.
• Other codeline streams: <CODELINE>[_<VERSION>]_<PURPOSE>[_<LEVEL>]
  Examples: APPROVE_portToVS2005, APPROVE_5-1_hotfix47
  These streams are used for e.g. hotfixes, service packs, substantial tasks, subprojects, teams, experiments and acceptance tests. Most streams will be single level, so the level can be omitted. In most cases, the version can be omitted as well, since it will be evident from the context (i.e. its parent stream).
• Snapshots: <PARENT STREAM>_<TIME>[_B<BUILD#>][_<PURPOSE>]
  Example: APPROVE_5-1_REL_D051127T1347_B6365_iRC01
  
• Workspace Streams: <PARENT STREAM>[_<host>|<number>]_<USER>
  Normally the default scheme should be used, where the AccuRev wizard attaches the user name to the stream name, i.e. the user name should never be explicitly written out when creating a Workspace!
  If a user has several workspaces on the same stream, they have to be distinguished by some kind of identification. For workspaces on different computers, the host name shall be used. For workspaces on the same computer, an integer number shall be used.
  Examples: APPROVE_DEV_3_tomas, APPROVE_DEV_buildserver12_tomas
  
• Reference Trees: <PARENT STREAM>_RT[_<PURPOSE>][_<host>|<number>]
  A reference tree cannot have the same name as an existing reference tree or workspace. In case of conflict, use the same distinguishing naming rules as for Workspaces.
  Example: APPROVE_REL_RT_NIGHTLYBUILD_buildserver12
  
• Pass-through streams: <CODELINE>_PT_<PURPOSE>
  No changes ‘stick’ to pass-through streams. However, include/exclude rules apply, so they can e.g. be used for grouping other streams/workspaces that share visibility rules.
  Example: Documentation_PT_APPROVE

<CODELINE> is typically a product or component name, such as APPROVE or Utilities

<VERSION> is the commercial product version, e.g. 5-1

<TIME> is on the form: Dyymmdd[Thhmm] Time is optional.

<PURPOSE> is used for additional comments:

• Hotfix number (HOTFIXyy)
• ServicePack number (SPyy)
• Release Candidates (iRCxx, eRCyy)
• Other useful freetext information about the purpose of the stream, such as:
  • For customer specific development (e.g. pilot projects): the company name
    Example: APPROVE_Volvo

For tasks: The task name and/or unique identifier
Example: APPROVE_PurchaseOrders