Posts Tagged ‘source control’

« Older Entries

Developer Recipes: AccuRev + JIRA + Eclipse using Mylyn

April 9th, 2008

Related Recipes: AccuRev + Eclipse + Ruby.

In this developer-centric recipe I am going to setup a power-tool trifecta consisting of Eclipse, JIRA, and AccuRev. I’m not talking about installing each independently. No, no, no. AccuRev + JIRA + Eclipse ScreenshotThis recipe is going to take things one step further and configure full bidirectional integrations for a wickedly powerful, fully integrated development environmentAccuRev + JIRA + Eclipse Chart where the majority of common day-to-day development tasks can be done right within Eclipse (right picture). Integrations are the crux of setting up a best-of-breed tool strategy and if you use these three tools you definitely want them talking together (left picture). Enough chop, let’s rock.

Install Applications

Let’s start by covering the basics and installing the latest versions of all three tools.

  1. Install AccuRev 4.6.x. download. Follow the install wizard. See the quick setup guide to import code and setup streams [Windows page 1 / Linux-page 13].
  2. Install Eclipse 3.3.x. download. Follow the install wizard. See documentation if needed.
  3. Install JIRA 3.12.x. download. Follow these instructions.

At this point, you have three independent tools installed. Developers can checkin/checkout code from AccuRev, use Eclipse to modify the source code, and track bug/feature development with JIRA. In all, not a bad setup. But toggling between all these tools just takes valuable time away from coding and there is no mashing of logically related meta-data to generate useful reports… such as:

  • “Which files/lines fixed issue #1234?”
  • “Was bug #5678 fixed in mainline, 2.x, and 1.x codelines?”
  • “Release is this Friday. How many issues are unresolved in the QA area and who are we waiting on?”
  • “Which fixes went into Release 4.5.101?”
  • “If I start working on the 4.x codeline, which known fixes will I be compiling against?”

Integrate Eclipse + AccuRev

Let’s eliminate jumping between Eclipse and the AccuRev CLI or StreamBrowser GUI. Rather, why not just keep/promote/update/merge directly within Eclipse. You can install our native Eclipse plugin via the Eclipse software updater.

  1. Help –> Software Updates –> Find/Install
  2. Select ‘Seach for new features to install’
  3. Create ‘New Remote Site’ named ‘AccuRev’ with URL http://www.accurev.com/download/eclipseupdate/32
  4. Checkbox ‘AccuRev’ and select Finish

When you create a new Project, choose to “Checkout from AccuRev.” Now the Eclipse ‘Team’ menu has a sleu of AccuRev commands available for inline use and your file navigator has icons for version control status. Sweet. Note: there is an AccuRev quickstart PDF located in your Eclipse plugin directory (e.g. /opt/eclipse/plugins/com.accurev.eclipse_4.6.1.32/UsingAB4Eclipse.pdf).

Integrate Eclipse + JIRA

Have you heard of the Eclipse Mylyn project? Seriously, it’ll bring a tear to your eye. In short, Mylyn is a generic framework for ‘task management’ within Eclipse and has a number of connectors to tools like JIRA, Bugzilla, and Trac. Guess what? You can interact with JIRA directly within Eclipse. It’s sick! seriously. Once again, you can install directly from the Eclipse software updater. First install the Mylyn framework and then the JIRA connector.

  1. Install Mylyn 2.0. Follow this setup guide. Basically, just like the AccuRev plugin above, create a remote updater site with this URL: http://download.eclipse.org/tools/mylyn/update/e3.3
  2. Install JIRA Connector. Follow the short setup guide provided by Atlassian.

As a developer, your world just got a whole lot better. Not only can you commit/update file changes directly within AccuRev, now you can open/close/update JIRA issues all without leaving Eclipse. Nuts!

Integrate AccuRev + JIRA

The final piece to the puzzle. Wait? What does hooking AccuRev to JIRA actually mean?!

Lets take a step back. Back in the day, using one of those other traditional branch-based SCM tools, you probably entered your bug #id into the commit comment. Commit 10 files. Enter bug #1234. Commit another 7 files. Enter same bug #1234. Very loose. And you probably had some validation and reporting scripts all stacked on top to keep things (hobbled) together. At the end of the day, this was far from a ‘tight’ integration and a struggle to maintain and enforce. Answering the simple question “which files -and- lines were fixed for bug #1234″ was not easy (probably impossible!).

AccuRev Change Packages. AccuRev has an out-of-the-box feature called Change Packages that natively tracks a set of files (as patches) regardless of the number of commits. Change packages are first class citizens in AccuRev. You can promote multiple times to the same change package and even remove files. The trick is to understand that a change package has a 1-to-1 relationship with… an issue! And those issues can come from JIRA. So as you work in your AccuRev workspace coding day-to-day you can promote your changes and assign them to a JIRA issue. Then make more changes and promote to the same issue. Think of it like this: creating a feature or fix may take 1 day or 100 days; 1 commit or 50 commits; Change packages don’t care. They just track the current set of files that you claim are ‘logically’ related as part of a fix or feature. That’s it! I’ll keep this short, but basically, you can now use the change package / issue as a new, first-class currency for promoting further up and/or patching those changes to other codelines! It’s very powerful. See pg 33 of our Concepts Guide for details. But I digress.

Back to the recipe. Hooking up AccuRev and JIRA means that AccuRev receives issues from JIRA and JIRA receives meta-data such as fixed files and versions for each issue. The setup requires our own connector technology called AccuBridge for JIRA. It’s pretty easy to setup and simply requires mapping JIRA fields to AccuRev fields and setting up the data synchronization. There is a well written ‘quick start’ guide to walk you through the entire setup process.

  1. Install AccuBridge for JIRA. download (link half-way down). Follow the setup guide located in the download package: doc/ais4jira_quick.pdf. [Note: Additional licensing may be required]
  2. Enable Change Packages. See pg 75 of the Admin Guide. Basically, you need to tell AccuRev ‘when’ to prompt users for issues, ‘which’ issues to query for, and which data columns to display in the lists. [Note: AccuRev Enterprise Edition is required]

At this point, developers are promoting file changes to JIRA issues and JIRA can report on ‘who’ fixed ‘which’ files for any given bug/feature/task. Now that’s what I call traceability!

All Together Now!

With everything hooked up, what do we have? Simple. AccuRev + JIRA + Eclipse ScreenshotAs a developer you can do just about everything directly within Eclipse. Edit files. Commit and update changes from AccuRev. Create issues and update comments/status/fields in JIRA. And behind the scenes, the JIRA records are being annotated by AccuRev as files are promoted out of Eclipse. Eclipse is your one-stop-shop workbench for developing, tracking changes, and managing task workflow (see picture).

Next we’ll add a build tool to the mix that integrates with AccuRev, JIRA, and Eclipse… But that’s for another day. Sounds great though, doesn’t it!

/happy coding/ – dave

7 comments »

Posted in AccuRev, Best Practices

Tags:

GNU Bash plugin for AccuRev 4.6

February 8th, 2008

I’m happy to announce the latest release of the GNU Bash programmable completion for AccuRev 4.6!

For those AccuRev users out there that know the true power of the GNU Bash shell, life just got even better.

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

The plugin requires GNU Bash 2.05+ and supports AccuRev 4.6.x. It was developed and tested using linux (Ubuntu 7.10) and GNU Bash 3.2.25.

Important note: While the plugin was developed by an AccuRev employee (me) and GNU Bash 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 tabbing/ – dave

1 comment »

Posted in AccuRev

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:

AccuRev is a Jolt Award 2008 Finalist

December 21st, 2007

AccuRev 4.6 for ClearCase, which includes our new ClearCase Coexistence Adapter, has been selected as a Finalist in the 2008 Jolt Product Excellence Awards! James has been sharing with you some of the core new features in AccuRev 4.6 in his previous posts, such as the VersionSlider and viewing work-in-progress at the Issue level, but for a more detailed look, check out the What’s New in 4.6 Web page.

2007 was truly the year of both SCCM conversion, and co-existence (a relatively new concept). While AccuRev added significant new features to its core offering this year, enabling co-existence with leading SCCM solutions is jolting in a number of significant ways.

AccuRev is the glue that allows teams to continue using their existing SCCM infrastructure, while integrating AccuRev into new or existing projects.  This eliminates risk and potential disruption associated with a comprehensive one-time conversion, and provides freedom of choice.

AccuRev 4.6 for ClearCase enables adoption of AccuRev in previously homogenous ClearCase environments, through real-time bi-directional synchronization without rework or porting. Ultimately, these organizations will save time, money, and deliver higher quality software.

Jolt Product Excellence Winners for 2008 will be announced at the SD West conference in March.

Happy Holidays!

No comments »

Posted in News

Tags:

How Accessible is Your Source Code?

December 19th, 2007

One of the things that frightens anyone who develops code the most, or more accurately the people who are responsible for releasing or deploying that code, is the possibility that you might not have access to it within your software configuration management tool or version control system when you need it. Computers are fickle things; unless you are prepared to spend fantastic amounts of money for a truly redundant hardware/software infrastructure, there is always the chance that your system could be inaccessible when you need it most. And this doesn’t even begin to address potential network outages.

AccuRev, because of the ease of backup and restore for one thing, and the always accessible locally resident Workspaces for another, is a great insurance policy against data loss and brings developer down-time to zero. But let’s say that one of those dreaded network outages or hard disk failures occurs exactly at the time when you need to pull the latest source over to your build system for a critical release. Or imagine any kind of similar roadblock you’ve run up against in your own environment. This is yet another area where AccuRev, with just a tiny bit of prep and foresight, can save you hours, if not days, of aggravation by ensuring that you always have access to your latest “buildable” code.

How does this happen? Well, consider first the AccuRev stream paradigm where – unlike branches – there is a well defined progression of code, from the high instability of a developer’s Workspace to the “always buildable” top-level release stream. You simply have to choose the stream that you would consider as your ideal location to retrieve “offline” code from. In the following StreamBrowser, I’ve chosen the top-level “Claims_Client” stream.

offline_code

Create an AccuRev reference tree based on your chosen stream. Define the location on disk where that reference tree should populate the code to. Then, use a trigger (we provide examples with exactly this functionality) to Update that reference tree anytime a Promotion happens into this stream. The end result is that you have a specific file-system location that is *guaranteed* to have the latest and greatest code from any given stream that you want. Also, this approach is optimized because it only has to transfer changes, not the entire source tree, and there is zero manual intervention required! So in the case where the network or SCM server goes down, no problem for you; your code is happily hanging out right where you need it to be.

Some organizations are much more tolerant of this kind of scenario than others. If so, can you think of other times or examples where this kind of functionality would be helpful to you?

No comments »

Posted in AccuRev, Tips and Tricks

Tags:

Selecting and Adopting a New SCM Tool

December 12th, 2007

by Damon Poole

Comparing SCM Tools

People often ask me “what is the best SCM tool” or “is there a comparison of SCM tools available.” I would say that generic comparisons of SCM tools are sort of like generic comparisons of cars. Somebody looking for something that is fast and doesn’t care about gas mileage probably wouldn’t think much of a Prius.

Currently, IMHO, the SCM market is not a commodity market where the products are generally about the same. There is a wide range in both pricing and functionality. So, you really have to know your requirements and the priority of those requirements. A good initial priority to figure out is: which is more important to the organization; price or return on investment? There’s no sense in looking at all of the tools on the market if there’s not enough budget.

Determining Requirements and Building Consensus Among All Stakeholders

Generally, a good way to acquire a new SCM tool is to start from a well defined set of requirements, create a shortlist of 3-5 candidates that seem close, take a closer look and narrow that down to 2, and then do a proof of concept on those 2 and pick the 1 that most closely meets your requirements.

Depending on the size of the development group and the size of the company, acquiring a new SCM tool can be an eye-opening experience. Finding a tool that meets your requirements is perhaps the easiest part of the process. Some of the harder parts are: figuring out who all of the stakeholders are, getting all stakeholders to consensus on the requirements, getting upper-management buy-in, and securing the budget for the purchase. Getting budget and requirements to match is generally the hardest part and typically involves writing some sort of business case to justify the purchase.

Here are some typical stakeholders: CEO, CFO, Purchasing Agent, Legal, VP of Engineering, Director of QA, key developers, and Release Engineering. Some of these may seem to have nothing to do with SCM, but they do get involved in large purchases that affect the whole company. It is better to make contact with all of these folks early to get the full scope of what is required to change SCM tools so as not to get surprised later and potentially impact release schedules.

If you make a recommendation that fits the budget and best meets the other requirements, but there is still a big gap in the requirements, don’t despair! If you’ve involved all of the stakeholders and built consensus, you have a good chance of leveraging that gap to increase the budget.

Start From High Level Use Cases

When moving from one software configuration management SCM system to another, it is often the case that people concentrate on “Which of the pains that I have in my current SCM system will this new system alleviate?” This is certainly a valid question. However, it is also important to ask “What benefits will the new system bring that perhaps I haven’t considered?”

Another common question is: “Our old system is missing a certain feature to compensate for a certain problem that the system has. We’ve developed a work-around for the missing feature. Does your system have the feature that is missing in our current system?” If the new system doesn’t have the problem that the old system had, then the need for the feature is often eliminated.

A better way to compare SCM systems is to start from high level business use cases. There are many ways to implement business level use cases for software development. Some of the implementation choices include: components, streams, tasks, and branches. An example of a business level use case is: “There are different versions of software installed at different customer sites. A defect is reported by one of the customers. The defect needs to be fixed in the version that the customer has as well as all other versions which have that problem.” The implementation of this use case will be different in a component-based and a stream-based system for instance.

When changing from one SCM implementation to another, be sure to start from your business level requirements instead of mapping from your current implementation to a different implementation. The reason for this is that the high level use cases do not require a particular implementation; they can be implemented using a variety of methods. If you have currently implemented the use cases with components, it is unlikely that directly mapping this implementation into streams will be the same as starting from the uses cases and implementing with streams. For most use cases, it does not make sense to map the way they would be implemented in your current system into a your new SCM system. While it is possible to do it, the result can be difficult to set up, understand, maintain, and use. This sort of implementation will also generally make it more difficult to realize the potential of your new SCM system. In other words, you may end up with the drawbacks of both worlds and the benefits of neither. The most successful approach will be to implement the high level business requirements into your new SCM system.

No comments »

Posted in Best Practices, SCM Resources

Tags:

Eclipse BIRT and AccuWork

December 6th, 2007

As a developer I’ve found it necessary from time to time to generate reports, especially for internal consumption. Internal reports tend to be more adhoc than those presented to clients or non-technology managers, and therefore have less time devoted to their care and feeding (and cost). While I’ve used Crystal Reports and similar tools for external reporting, most development reporting has consisted of spreadsheets and any charts that they generate in the ten minutes I have before a review meeting.

Always wanting to explore various technologies, I took the opportunity to try my hand at using the BIRT (Business Intelligence and Reporting Tools) implementation in Eclipse. If you’re interested in finding out specifics about this plugin, you can find it on the Eclipse web site. While I find the tool to have a higher learning curve than I would have expected, it shows promise for the future.

There are a number of data points that we generate as part of our development, and capturing all of them in a report format proves to be a surprisingly complex task. It is a task that gets little time and investment, as development goals are not report oriented, they are product delivery oriented. I’ve attempted to capture some of the more mundane details, and set aside future report details that require a larger effort. I’ll be describing what I’ve done to create the reports, but not really discuss about why or how to interpret the data. A discussion of some other data and what you can do with it can also be found here.

Here at AccuRev our projects are issue oriented. We use AccuWork, which is our own tightly integrated issue management environment.

Given that, and the goals for the reporting that I defined, I had to find a way for AccuWork to communicate information that BIRT could interpret. In the past using Excel, I’d simply query issues in AccuWork and export the data into an HTML table that Excel could then read in and, with the help of pivot tables, generate the desired reports. The basic information reported included:

  1. Number of issues per developer
  2. Count of issues by priority per developer
  3. Distribution of issue resolution (Whether issues are duplicates, regressions, cancelled, deferred, etc)
  4. Distribution of issue severity (Whether issues are crashes, major implementations, cosmetic, etc)
  5. Weekday issue completed per developer
  6. Weekly Find rate vs. Fix rate
  7. Weekly average number of days to complete issues

Using this information, it is easy to see projects taper off to closure, as well gather some ideas as to how the developer workload was being distributed. Some developers cringe at this information, but I believe as long as it is used positively and to evenly distribute work, then everyone gains from reviewing this information.

With these same charts in mind, I loaded up my version of Eclipse, installed BIRT and its associated plugins, and started to figure out how to get the data into the tool. » Read more: Eclipse BIRT and AccuWork

2 comments »

Posted in Tips and Tricks

Tags:

Arming Software Development Project Managers with Real Data

November 30th, 2007

Managing software development is tough enough as it is. Managers take responsibility for the results their teams deliver. They’re on the hook for hitting schedules, delivering quality, and meeting customer requirements. Worst of all, if they’re saddled with slacker engineers, they still have to get the work done, and done right.

Tools are needed to help managers stay on top of their projects and find problems when there’s still time to fix them, before the schedule pressures explode. Project management tools are valuable, but their schedules only reflect the quality of the information that went into making them. Garbage in, garbage out.

The SCM system is the source of the information that drives smart decisions. Here are four sources of real data that can come out of any quality SCM system. I’ll illustrate with AccuRev because, well, because it’s the best.

  1. Bug Arrival Rate
  2. Churn rate
  3. Task Estimate accuracy
  4. Complexity Creep

1. Bug Arrival Rate

A key graph in any project manager’s arsenal compares bugs reported over time against bugs closed over time. Here we use AccuRev’s AccuWork issue tracking tool to store all issues, whether reported by QA, sent in from customer service’s CRM, or entered by the powers that be as customer requirements. Since our iterations are four weeks long, we use the week as a reporting time period. Some AccuRev customers use days.

In AccuWork, queries are easy to create, and we get a report from AccuWork in XML covering all the issues opened or verified [foot note: In our terminology, developers “close” issues, and QA “verifies” them. Other companies have developers “submit” issues and QA “close” them] against a particular iteration.

The XML slides right into Microsoft’s excellent Excel 2003. I use PivotTables and Excel graphs for all my reports. Others might leverage their superior Perl skills.

Here, we add a “week” field based on the AccuRev time field.

lorne_pic_final

2.Churn Rate

A key metric for quality is how often different parts of the code base have to be modified to address issues. Here, the AccuRev code repository has all the information we need. I use the AccuRev Hist command

accurev hist –a –s “release candidate stream” –fx –t “2006/1/8 – 2006/1/1”

to get an XML file of all the “Promotes” (sort of like “check-ins”) to a release candidate stream within a time range. Some use a separate “hist” command for each release period. Personally, I take a big time range and then use Microsoft’s Excel 2003’s XML file support to slice and dice into tasty chucks. I tried it once with Excel 2007. Once.

Since we component-ize our code base based on directories, the “path” field is particularly interesting, as directories can be as significant as individual files.

Loading the XML file into Excel, my macro deletes some unneeded columns and creates a Pivot Table like the following:

lorne_pic_2_final.gif

Here I’ve filtered the data to not include the binary files, and used the Excel Pivot table’s advanced feature to show the top ten in descending order. AccuRev.c takes a beating every release but it isn’t significant. Server/diff.c and Client/stat.c seem to be at the center of a lot of changes that release, and are probably candidates for some code reviews.

3. Task Estimate Accuracy

Along with dates of issue opens and issue closes, we have chosen to include a user field for the original estimate of the length of time it will take to complete the issue. That gives us something to compare to when we “close” an issue and send it to QA, and an opportunity to correlate against the length of time before an issue gets verified.

As a best-practice, we try to normalize issues to a couple of days in length. Longer and you haven’t really figured out what needs to be done. Shorter and you’re liable to strangle in your own spit, a management practice I can’t recommend having seen the results.

We get this data out of AccuWork again, and can slice it by group, release, or even individual developer. This is a quick way to quantify the subjective feel we all have for who is slow, who’s fast, and who’s clueless. Here’s a scatter plot for a group. Note that they are generally on the high side of their estimates, and that they haven’t done a very good job normalizing tasks to 2-3 days:

lorne-pic-3-final.gif

4. Complexity Creep

As software gets modified, and especially when managers become conscious of the amount of time taken to fix a bug or implement a feature, there is a tendency for developers to make the code base less maintainable. There are some metrics for code complexity that can benefit the manager when trying to assess when it is time to refactor. A frequently used metric is cyclomatic code complexity.

While we don’t do any code complexity measurements here, some of our larger customers do. This is easy to collect using a trigger on changes being sent to a release candidate (or QA candidate) stream, where the trigger calls the analysis tool and puts the results into a tab-separated file for later plotting from Excel.

A simple (Perl) implementation of the server side “server_post_promote” trigger creating a file “complexity.txt” looks like:

open COMPOUT, “>>complexity.txt” or die “Can’t open complexity.txt”;
if ($stream eq “acmeProj_QA”) {
$complexity = complexity($stream, $version, $workspaceDir, $filePath);
print COMPOUT “$user\t $date\t $transaction\t $stream\t $version\t $filePath\t $complexity\t $issueNum\n”;
}
close COMPOUT;

Together, these reports provide a good mix of data around schedule, estimation and code quality, giving our beleaguered project manager a pretty nice set of armor.

Please post your favorite management reports, even if you don’t (yet!) use AccuRev.

2 comments »

Posted in AccuRev, Best Practices, Tips and Tricks

Tags:

AccuRev 4.6 preview nuggets – redux

November 28th, 2007

AccuRev is tremendous when it comes to managing the Software Development Process; you have complete visual control over how code will flow and progress through the stages you feel necessary as an organization.  This kind of capability generally appeals to folks at the executive level, or release and build engineers, or project management.

We haven’t forgotten about the developer though!  In 4.6 we’ve introduced the “version slider,” which allows  for a complete visual history of any element under source control, along with complete groupable annotation.  Quickly drag the slider to any previous point in time and you’re able to see what changes encapsulated that version, who made them, and group by various fields. You may have seen a similar screen capture to the one below from AccuRev in the pages of SD Times recently? Here’s an article on change management you may find of interest there as well.

4.6 preview slider

I’ve never been a fan of the expression “blame game,” but for the detectives out there, this puts the clues to the Who, What, When, Where, and maybe even Why (if comments are used appropriately) of code change at your literal fingertips…

1 comment »

Posted in AccuRev

Tags:

AccuRev 4.6 preview nuggets

November 21st, 2007

As we head into Thanksgiving here in the United States, one of the things AccuRev customers have to look forward to on the other side is the upcoming 4.6 release. I thought this might be a good time to start giving some preview tidbits of 4.6 core functionality that would be of interest.

As you already know, the AccuRev StreamBrowser gives you a complete visual representation of how code is flowing through your system, not to mention dymanic control of the development process. And the “shamrock”, or default group icon, lets you know specifically what elements have been worked on at each stage. Well, with 4.6 you will now be able to see work in progress at the Issue level instead of just the file level:

4.6 preview default group by issue

This top-level visibility into what Issues have progressed to what areas of your development process further abstracts the team from needing to worry about individual elements, and instead they can concentrate on the bigger picture: “Am I going to get this release out in time?” Or “Do I not have enough of my core features past the QA gate yet?”

You can also still show the default group by file, and additionally you can view by transaction as well. Ponder this while fighting off Tryptophan induced sleep. Many of you asked for this feature and I look forward to learning how you will make use of it.

No comments »

Posted in AccuRev

Tags: