It’s here! AccuRev today announced Kando, the seamless integration of Git with the AccuRev server. Everyone at AccuRev is incredibly excited about it.

As many people know (and as we discussed here last week), Git is increasing in popularity among developers working in small groups or collaborating on open source projects. It’s also fast, flexible, and full of developer-friendly features. But when it comes to using Git in an enterprise, the size and complexity of these environments can make it difficult to secure and manage the software development process.

What makes Kando different from other Git integrations?

Take a look at the diagram below. With Kando, Git developers push and pull from real Git repositories. Kando takes all changes pushed to these repositories and replicates them on the AccuRev server. Furthermore, any changes made in AccuRev streams that are mapped to Git repositories are replicated in their respective repositories. This means Git users can just do a pull to get those changes, which allows Git users to continue using Git as usual without interacting with AccuRev, if they choose not to.

 How does Kando benefit Git development environments? 

Kando enables the flexibility of Git and the security of AccuRev by providing:

• Support for enterprise authentication via LDAP and Microsoft Active Directory
• Fully integrated issue tracking system and Software Change and Configuration Management (SCCM) through change-based development with AccuRev Change Packages
• User and group-based access control security measures
• Visualization of development processes using Git through the AccuRev StreamBrowser
• Seamless integration of Git into an AccuRev environment

Take a look at how it works:

To read more about Kando, watch the demo video, and learn about beta availability, check out the Kando page here!

Mammoth retailer Target must have had very high hopes for big sales when a new designer collection went on sale last week. Unfortunately it ended up being a bust. (The site quickly became overwhelmed and crashed several times throughout the day.) Online retail experts say losses for the retailer could run into the millions as a result.

Scenarios like this are not new, though with a large retailer like Target, it was somewhat surprising. The painful reality of eCommerce is when transactional websites experience dramatically increased traffic, there is always a chance that, without well maintained software development measures in place, crash scenarios like Target’s will occur.

When an eCommerce crisis like this occurs, developers go into fire drill mode to make rapid changes so the site is back up and running as quickly as possible. Software change and configuration management tools play a crucial role in both ongoing updates and crisis management updates, like the Target example.

It’s also important to note that traditional SCM tools won’t cut it when it comes to high volume transaction web sites like Target, Amazon or any major retailer. Most retail and eCommerce sites need enterprise SCM tools that can scale to accommodate large, geographically distributed teams of developers working in parallel. More advanced SCM tools are integral to the success of transactional web sites, both from a day-to-day aspect, and when there are spikes in traffic and transactions for special sales events, promotions, and holiday shopping.

While last week’s incident demonstrated what can go wrong when an eCommerce site experiences significant problems, there are some great stories out there as well.

One such example is that of a very large and well known travel eCommerce site that receives an average of ten million visitors a month.

As with most of the top of travel eCommerce sites, this one is very dynamic. Users can make reservations for airlines, car rental, hotels, sign up for text message alerts about delayed flights, rate their own experiences and much more.

While these features are popular with consumers, these transactional environments are highly complex to manage. At this particular website, there are as many as 40 different development teams working on 40 different projects. One “project” might be car rentals, another hotel reservations, etc.

When development environments have this much complexity, when teams are working in parallel on a wide variety of projects, only the most powerful SCM tools can help minimize version control problems that lead to bugs slipping through. What may appear at first to be a minor issue can, in the worst case scenario, cause an array of site problems and crashes that have a direct impact on the consumer and revenue. This travel site, which uses AccuRev’s SCM solution, is able to do everything possible to ensure the site and the software behind it stay up and running smoothly, 24/7.

The web storefront is a business critical tool for any type of eCommerce business.  For these reasons, enterprise level SCM tools under the hood are essential to success.

What other similar success and web crisis/failure stories have you experienced directly or heard about?

Are you frequently called on to perform the daunting task of ‘the merge’? Does tension mount and do groans grow louder when it’s time for a merge?  Are only a select few are willing to stand up and do the work?

Maybe these stages describe your merge process:

1. Denial: It’s never going to work (in a timely manner).
2. Anger: Why do I have to do the merge?
3. Bargaining: I’ll work on maintenance and support if I don’t have to do the merge.
4. Depression: How many compiler errors? Why won’t the jsp work with firefox?
5. Acceptance: Not really, it’s compiling and (mostly) passing tests.

Before we try to get you through the 5 stages of merge, let’s a take a look at divergence, the cause of a complicated merge.

Converging Divergence

There are lots of reasons for divergence, and as many for merge product lines back together.

Maybe you’re delivering functionality to specific customers, creating customization and personalization of websites, internationalizing your product, even moving from Windows to Linux platforms. So what happens? These areas diverge, developers refactor code, and the product lines look very, very different over time. Sure, you try to propagate changes across the product lines, but each implementation is slightly different. Eventually you realize this is a maintenance nightmare, and some shared areas should be brought back in line (if not the whole product line moving to a single source).

Now comes the hard part. A select few of your developers have to start piecing the code back together. Determining what changes are acceptable, reviewing the functionality, and hopefully getting the appropriate test coverage to verify that the desired changes have been brought back into a single (or at least cleaner) product line. Here’s where tools really shine (or falter).

Now, I consider myself pretty experienced in the merge department. I’ve worked on a number of merges of different sizes, dealt with multiple languages (English/Italian), and even migrated to different platforms (Moving from Windows to Macintosh).  Sometimes, I found, tools were a complete hindrance- I remember back in the day, using PVCS or CVS was every man for himself. You just got it working, never mind worrying about who made what code decision, and hopefully extensive tests identified the problems. More modern tools, AccuRev in particular, give you another dimension with merge that I find to be an essential.

The Merge Master

AccuRev version tracking, and the changes it tracks (content, name, removal) really help in hunting down the straightforward changes that can result in truly subtle changes in product behavior. Simply knowing that files have been removed in one product, and merging those changes over with a click of a button can eliminate behavior that is hard to determine, especially when the developer doing the merge had a reasonable belief that the files may exist.

Even better, large or midsize merges, can be easily reviewed, grouped into areas of the code and dealt with in a manageable manner. I performed a merge that merged internationalization changes into a product at AccuRev. There were over 7000 files that were altered, added or removed that needed to be managed.

Simply grouping the files by directory structure quickly identified which were doc, help, client, java, etc. Then these areas could be dealt with by developers in the specific areas. Further, because AccuRev performs simple merges quickly, I was able to perform the initial merges in these areas without having a strong need to understand them, and leave the complex changes to those who specialized in particular areas. This further reduced the amount of effort (and pain) that other team members experienced.

In this 7000+ file example, only about 400 files actually required more specialized investigation. And of the 400, only about 50 had truly complex changes where both sides of the merge made what looked like contrary decisions. Here is another place where AccuRev shines. By looking at the changes made at different points in each of the product lines, and working with change packages that described what the developers where trying to accomplish, I was able to make intelligent decisions about how the code should integrate, instead of just picking ‘he who changed it last’.

The two product lines in this case had diverged for about 9 months, and had about 10 developers making changes in each product line. Even with the amount of changes that occurred over this time period, it only took a single developer about 2 weeks time to bring the two product lines together. It took only a couple of days to complete the initial code process, walking through the changes and picking (via the AccuRev GUI) which of the changes to take, and editing inline where it was obvious.

During the first week, we were able to finish digging around developer changes via the AccuRev version browser in order to help resolve initial compilation failures. This work brought the product to the point where it was compiling on multiple platforms (which is usually even a problem with nightly builds). After another week of going through the validation and user tests, the merge was stable enough to be considered the baseline for the next release. Of course development had already occurred during the two weeks that the merge process took, but with the version tracking AccuRev performs with merges, it became almost trivial to bring in the new changes- within 1 day they were validated and ready to be the new baseline.

Sounds like acceptance to me.

More Agile resources

AccuRev is hosting a free Webinar on “Emerging SCM Best Practices for Agile Development” on Thursday, February 5 from 1:00 – 2:00 PM EST. The webinar will introduce the unique demands that agile processes place on legacy SCM tools and ways to build and automate an efficient Agile development process. Damon Poole, AccuRev CTO, and Uttam Narsu will be presenting.

Mr. Narsu, an industry expert on software configuration management (SCM) best practices and former Forrester/Giga analyst, will discuss the most important aspects to consider when applying SCM best practices to an agile world.  Mr. Poole will discuss how Multi-stage Continuous Integration can solve some of the underlying impediments to a successful Agile development environment.

“SCM is critical to Agile success. If your SCM tools don’t provide integrated and seamless support for Agile, you won’t get widespread adoption of Agile development,” said Narsu. “Development teams require brutally efficient SCM tools, but the tools must still be issue-based, must have support for flexible process models, and enable efficient branching, merging, and refactoring. The SCM tool should also provide private workspaces and assist continuous integration.”

Mr. Narsu has worked with hundreds of clients using wildly differing software development environments. While clients who succeed with agile development have strong SCM practices, the best practiced agile SCM: transparently integrated, flexible, and collaborative.

Specific topics discussed will include:

• Typical SCM obstacles to Agile success and how to avoid them;
• Key Agile Process requirements for SCM products and specific use case scenarios;
• Challenges with continuous integration, and how Multi-stage Continuous Integration delivers value and how to adopt it today; and
• Key SCM metrics for delivering on Agile development goals.

Register here for this free webinar taking place on Thursday, February 5th from 1:00-2:00 EST: Emerging SCM Best Practices for Agile Development.

AccuRev is once again pleased to inform everyone that its flagship product, AccuRev, has been selected as a Jolt Award Finalist for Dr. Dobb’s 19th Annual Jolt Product Excellence Awards in the Change and Configuration Management category. 

For the past 18 years, the Jolt Product Excellence Awards have been presented annually to showcase products that have “jolted” the industry with their significance and made the task of creating software faster, easier, and more efficient. The awards presentation is sponsored by JOLT, the fabled soft drink quaffed by software developers for sustenance during project development marathons.

“The Jolt judges have selected these finalists from the nearly 300 qualified nominations that were submitted online. The submissions represent the many innovative tools available for every phase of the software development lifecycle,” said Amber Ankerholz, Jolt Award Project Manager. “This year’s finalist round was extremely competitive and we appreciate the effort all of the participants put into showcasing their products’ features for the judges.”

In the next round of the Jolt Award process, the judges will examine the finalists according to the standard criteria of audience suitability, productivity, innovation, quality, ROI, risk, and flexibility. They focus on products that are ahead of the curve, universally useful, rich in functionality or that were solutions to problems in their product space.

Winners are announced during the Jolt Awards ceremony that takes place on March 11 at SD West 2009 Conference & Expo at the Santa Clara Convention Center.

As an AccuRev blog reader, you’re welcome to attend our upcoming free webinar that will discuss the intersection of Agile development and governance:

Attend this Webinar and learn:

How Agile processes and compliance can coexist in harmony

What pragmatic ALM is and how it can help you solve today’s business challenges

How to manage multiple processes dependent on project requirements (Waterfall, Agile, etc.)

Best practices for optimizing tools and processes for both software development and release management.

When: Thursday, December 4 at 1:00 PM EST

Register: The Business Case for Pragmatic ALM: Agility with Governance

By Matthew Laudato

When I read the following blog, Developing in branches, releasing from trunk about a software configuration management development process that was constrained and tortured by branches, I had an ‘aha’ moment. Actually, I had three moments. They went something like this:

1. Branches are obsolete, so why does anyone still use them?

2. People use them because they are unaware of the alternatives – specifically streams.

3. I must act quickly to save my coding comrades from any further branch related pain.

If there is a cyberspace equivalent of shouting from the rooftops, then this blog post is it. My goal is to help the author to simplify his development process, and to free him and his team from the time-wasting, error-prone, outdated branch-induced hysteria that is clearly evident in his post. OK, so maybe that last sentence was a little hysterical, but you get the point.

In the post (which I encourage you to read first), the author outlines a branch-centric process that goes something like this:

- create issues in JIRA for feature (defect, etc) work

- create a Subversion branch for each JIRA issue, named by the JIRA issue ID (eg, SUP-3452). Developers write code on these feature branches.

- create a JIRA release (for example, R4.2) and target the issues created above to this release

- create a Subversion branch (off of the ‘trunk’) with the same name ‘R4.2′.

- Write a bunch of scripts that look at the JIRA release, find all the issues for that release, look at Subversion for the branches that are named for said issues, merge these branches to the release (R4.2) branch.

- Do some testing on the R4.2 branch

- Tag the release R4.2 branch

- Release software

- Merge the R4.2 tag back into the trunk

Rinse, repeat for the next release.

For some reason, I’m reminded at this point of a character in Tom Robbins’ “Even Cowgirls Get the Blues”. The character had a little business card that he would hand to people. One one side it read, ‘I believe in everything, nothing is sacred’. On the other side it read, ‘I believe in nothing, everything is sacred’. When I think about the author’s process, one side of my brain says ‘there is nothing wrong with this process’, and almost immediately, the other side screams ‘there is everything wrong with this process’. The truth is somewhere in the middle, and it all comes down to branches.

The problem with this process is that branches get in the way. The idea of isolating features in your SCM tool is a good one. Although I don’t personally agree with the idea of dedicating an SCM construct per-feature, there are plenty of people who do. (See Stream-per-task paradigm, for example by Dave Thomas). But that’s not the point. Whether you put one feature or ten in it, a branch constrains your ability to work efficiently. Once you create a branch, it loses all contact with the outside world, most importantly, with its own history and its relationship to other branches. The author even admits jokingly that a ‘release manager’ will likely be needed to handle the merges. Ya think?

Here’s an alternative process that uses AccuRev streams:

- Create issues in JIRA as before for the desired features and fixes and assign to developers. Use AccuBridge for JIRA to sync those issues into AccuRev

- Create a stream for R4.2

- Create (or reparent existing) developer workspaces off of this stream.

- When developers finish coding, they use ‘promote to issue’ to push the code to the R4.2 stream (automatically creating a change package that associates the code changes with the JIRA issue, and automatically updating the JIRA issue with an annotation about said code changes).

At this point, the R4.2 stream contains everything that you want to release. If you decide to back out a feature, you can use the revert by change package feature to remove it from the stream. The code changes are always available in the developer’s workspace if you need to revive them in the future. Once it is time to release, you can create a snapshot of the R4.2 stream to preserve it, and then you can go about working on the next release. If R4.2 and R5.0 (The Next Big Release) are happening in parallel, you could create an R5.0 stream as a child of R4.2, so that the R5.0 stream automatically inherits all of the R4.2 changes.

The advantages are many:

- Fewer and simpler merges

- Right-sized feature isolation and management

- Inherent parallelism through code inheritence

- Fewer process steps

- Built-in automation and thus fewer opportunities for manual errors.

I could go on, but I hear the footsteps in the hallway. There are people out there who don’t want you to know about streams. “We’ve always used branches,” they’ll say. “We’re too smart to use some vendor’s solution,” others will say. I say, don’t listen to them. Fight the power. Walk right up to them and say “Why branch when you can stream?” And then go ahead and watch your team spend less time fighting with branches and merges, and more time writing features and fixes for your customers.

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.

First, for all of you English majors out there, yes, the title is a deliberate play on words. My initial inclination was to use ‘wither’ instead of ‘whither’, to imply that SCM systems that still used branches were dried up and rotting legacies of a less enlightened past. But since this post is a response to a blog I read about the limits of branches, I though ‘whither’ was more appropriate, as I am really talking about the overall disposition of branches and how they should be used.

The author of “Is branching the answer?” poses several interesting and important observations about the limitations of branching as a means to push source code through a development process. My goal in this post is to show the reader how AccuRev addresses those issues.

To begin with, the author correctly notes that branches are often used to identify stages in a development process, and that merges are then used to ‘promote’ code through these branches as the code evolves. My first comment is on private branches, which AccuRev replaces with private developer workspaces. Private workspaces are essentially full SCM environments on a developer desktop, as opposed to the copies that private branches in, say, Subversion are. The practical difference is then when you promote from an AccuRev workspace, merges are required only for those changes that are in conflict with existing changes in the parent stream. The general case is that promotes are clean and do not require merges at all.

The author then lists four problems with the approach of using branches to ‘automate sharing of code changes within a team’. For most file and branch based systems, I tend to agree with the author, so my comments are on how AccuRev addresses these issues:

1. It encodes the team’s process into the file history of code making it difficult to quickly adjust the process as team conditions change.

With standard branches, that is true. With AccuRev, streams represent how code flows through the system. File histories reflect the individual ancestry of files. Since streams can be easily reparented, there is nothing difficult about changing the process.

2. Using a merge to promote changes introduces the possibiliy of an incomplete or bad merge that hides its effect, namely that the code isn’t promoted, or worse additional code is injected that doesn’t belong.

Promotion is a fundamental operation in AccuRev. Code changes are designed to be pushed up the stream hierarchy, from developers, to QA, all the way up to release. The only required merges are those that arise naturally from conflicts, and AccuRev’s merge tools make it straightforward to assure that merges when required are performed accurately. There are absolutely no ‘merges that are simply code promotions’. Also, it is impossible in AccuRev for anything ‘incomplete’ to get promoted. AccuRev uses atomic transactions for all operations, so success or failure is binary.

3. It clouds the history of file changes with multiple merges that make it difficult to understand if changes have correctly been merged and makes it hard to understand what is in a build of the software.

See previous response. One additional comment – there is no magic bullet for merges. AccuRev helps you identify when a merge is required, but to my knowledge there are no tools that help you decide whether changes have been correctly merged from a semantic point of view. Put another way, AccuRev can tell you that lines 3 and 4 are in conflict and require a merge, but only a human being can know how to properly resolve the conflict. That’s why they pay us the big bucks! As for what is in a given build, atomic transactions in AccuRev and the TimeSafe architecture assure that the contents of a given stream are unambiguous at any point in time.

4. It makes it hard to promote code to software teams that don’t have a close common branch. For example, you want to merge a fix from one project to another but the only common branch is the main line and merging there will hit production before you want to.

Streams make it easy to isolate lines of development from each other, especially for this common case. There is no need for a ‘common branch’ in order to do this. You simply place the changes of interest on the change palette and select the destination stream.

As to the author’s final point about Telelogic Synergy and change set routing, I will just say that AccuRev change packages provide a logical grouping of changes that can be promoted, reverted and routed in a similar fashion.

Overall, this was a very interesting post and I congratulate the author on identifying and commenting on the problems with branches in release management.

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