By Wayne Blair, Senior Consulting Release Engineer and Development Facilitator

Hot backups are wonderful but one needs two important sanity checks on the backup:

1. Was this a good backup?
2. Is the live database okay or did we just backup a corrupted repository?

Unfortunately AccuRev v4.x cannot perform a database integrity check on the running repository so you have to schedule down time but you can run the “maintain” utility on your backup repository on a different machine with a minor change to the acserver.cnf file.

These steps can sanity check both your backup and your live repository at the time of backup without any down time using the behavior of the “maintain” utility.

1. Write a backup mark using the command “accurev backup mark”.
2. Replicate your entire accurev installation directory tree to another machine running the same operation system. You want the data, executables, configurations, and license key.
3. Edit ./bin/acserver.cnf and change the machine name from your live repository to the name of the “other” machine”. MASTER_SERVER = your_other_machine.organization.domain
4. Run the command “./bin/maintain dbcheck”.

If the command fails due to a host name error then review your edit for faulty white space (the white space before and after the = is required and you must not have trailing white space after the host name).  If the fully qualified name fails, try using the alias (short) name or IP address.

Assuming a successful dbcheck, you have now verified the integrity of your backup and you have verified the integrity of your live repository as of the time of the last backup mark command.

DETAILS

The AccuRev license is tied to a specific host and port number and you must have a different license file to run the AccuRev repository on a different machine.

The maintain utility performs a sanity check on the license and will exit when the license file is missing. It will check on the host name and will exit when the running host name does not match the host in acserver.cnf but will continue to perform the database integrity check when they do match!

My AccuRev server is Linux based so I run an hourly cron job to write the backup mark then rsync the whole installation to another machine.  I intentionally use the –delete option to ensure the backup is identical every time so the edits I apply to acserver.cnf will be eliminated the next time the backup is run.

Here is a trivial sample script to perform the backup with rsync.  I am writing this from memory so please verify the rsync syntax with the trailing slash on the directories.

# ASSUMPTION: ssh keys are already established between this host
#             and the remote host to allow an automatic login.
#
# NOTE: Be sure the previous run of this script has completed before
#       running again.

/opt/accurev/bin/accurev backup mark
sleep 3
rsync -az -e ssh --delete \
/opt/accurev/ \
wblair:/opt/accurev

About The Author

Wayne Blair was invited to contribute to our Distinguished Lecturer Series because of his experience as a consulting release engineer with multiple AccuRev customers.  Mr. Blair has extensive experience creating and extending software development, release, and installation environments, and helping communicate technical information to non-technical people.

The new AccuRev beta release is customer’s first look at Version 5.0 of the AccuRev server.  The key new element has been porting the AccuRev server to an ODBC database.  Initial reports show that this will provide enhanced scalability and more flexible IT architectures that large AccuRev deployments have been looking for, without degrading the one-user path length. While the functionality will be familiar to any post-R4.5 customer, there are many enhancements and bug fixes that have migrated into 5.0, making this an even larger improvement from R4.0 than it was from R3.0.

The first database supported by AccuRev, and the only one supported with the beta test of Version 5.0, is the PostgreSQL DBMS.  PostgreSQL (pronounced “post-gress”) is a sophisticated DBMS with good concurrency support for complex locking models, rich support of database features, and broad platform availability.  The postgreSQL.org site contains lots of ancillary material, including a list of books on PostgreSQL for the interested developer.

One of the features of ODBC database support is the ability to use familiar database tools to create reports and real-time dashboard data.  The AccuRev server schema is very complicated with multiple databases, many tables, and complex fields.  To simplify reporting, we have developed a database View for this blog post that abstracts AccuRev database internals into a more user friendly form, perfect for use with report generation tools.  This database view will be available from the AccuRev User Forums, and will be updated to include other features based on customer request.  The database is not directly customer accessible for modification and users should not make modifications or additions to the AccuRev database. Fortunately, Views in PostgreSQL are read-only, which is another safety guard against accidental database modification.

Tools such as Crystal Reports® or BIRT™ provide user interfaces for report generation that work directly with tables in a relational database.  They provide a simple drag-and-drop, wizard driven, interface, making report generation and formatting much simpler than coding SQL statements directly.  Business Objects (owned by SAP, and maker of Crystal Reports) and Actuate (BIRT provider) both have real-time update report tools, for creating near-real-time dashboards.  These are not covered by this blog, but would use the same PostgreSQL view.

The first report we want to develop is one that shows the transactions in a stream, broken out by users.  I like this graph because it shows exactly who contributed changes to a particular release candidate. We used Crystal Reports to generate the template.

Crystal Reports Transactions Template

All the “action” is in the design area at the bottom.  We used the Group wizard to add the name, sum the number of promotes, and generate the graph.

Crystal Reports Change Contribution

Another report is the rate of changes to a series of streams.  This shows the rate of instability in a project, which might not be reflected in the issue tracking system.  Here we show the number of transactions in a series of streams each week, for the past ten weeks.

CrystalReport Rate of Change Template

And we’ve limited the report to just show the three streams of most concern.

Crystal Reports Stream Changes

In conclusion, Version 5.0, coupled with AccuRev’s new Web User Interface, is an exciting new version of AccuRev that promises to provide benefits to the AccuRev community, both large and small, for a long time.

Vlad Romanescu &

Rob Mohr

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.

After building your software, do you check-in your generated binary  files? How about the output from test runs? If your software runs on multiple platforms or your test runs take hours/days to execute, you may want to consider storing the output — especially if binary reproducibility is critical.

Example. Consider shipping an application to a customer who 2 years later reports a defect. Can you reproduce their build “today”? Surely you have the exact versions of source files. But are you using the exact build file? Probably. How about the original version of the compiler? Maybe. But probably not. Don’t forget that your compilers get upgraded too — their optimization algorithms or bugfixes can change the binary execution format of your application. Thus, compiling source from 2 years ago may result in an equally functioning application at the user-level, but at the byte-level, things may have changed dramatically — and at a level where runtime defects (performance/memory) rear their ugly heads.

Myth #1: Committing generated  files results in longer checkout times. No developer wants to checkout source code and wait for or be inundated with megabytes of .o, .class, .jar, .war files that they are either never used or are going to be rebuilt anyway.  The AccuRev Truth: Use include/exclude rules on streams and workspaces to control which streams have access to generated objects and who will receive them during checkout.

Myth #2: Committing binary files slows down your CM system. Traditional SCM systems combine both meta data and content resulting in slower performance over time as the number of files increase (think labeling).  The AccuRev Truth: AccuRev stores meta-data separate from file contents and uses indexes to lookup and retrieve contents.  For example, transactions are labeled not files.  Using a card catalog (index lookup) to find your books is always faster than walking the isles (linear scan).

Myth #3: Storing generated artifacts will bloat the repository. Back in the day of wild-west coding, there was little rhyme or reason for where files were saved in the source tree.  The build system would simply compile the files it found, save the generated output right next to the source file, and as long as everything linked & compiled — it worked.  But in todays complex world of multi-layer software architectures, tiered deployments, mixed technologies, and sophisticated build tools, following a convention is almost a necessity (think  ruby on rails, maven, etc). The AccuRev Truth: Organizing the top-level source tree and configuring your build tool can make it very easy to carve out source vs. binary vs. tests vs. scripts, etc.  Using include/exclude rules, end-users can decide at the stream or workspace level what parts of the file tree need to be visible.

The Pattern. In this pattern for versioning generated artifacts, I’ll show how streams can be used to store generated files only in the appropriate stage of development and prevent unwanted exposure to developers.  Two options are present that can also be used in combination.

Option #1: sub-configurations

Option #1: Store and track generated artifacts as sub-configurations isolated from the mainline.   From a baseline snapshot such as a test build or release candidate, create a new child stream to store the generated artifacts.  Then create a second snapshot that represents both source code and generated artifacts. For a single “configuration” you now have two snapshots – one for source only and a second for source + binary.  Furthermore, you can diff these two snapshots to know exactly how the binary configuration is different from the source configuration.  You might also consider storing compiler files, debugging output, test output,the compilers themselves (!), etc.

Option #2: include/exclude rules

Option #2: Store and track generated artifacts directly in mainline but exclude them from downstream access using stream-level exclude rules.   The top-most streams that need access to both source and binary will include the majority or entire filesystem footprint in their configurations.   The first stream that does not need access to generated objects will likely be the candidate to set an exclude rule on the folder(s) that contain those files.  The exclude rule is inherited to all children and grandchildren.

When using exclude rules, it is easiest to set a single rule on a top-level ‘./build’ or ‘./generated’ folder rather than creating a rule for each sub-folder in a large source tree.  Traditionally, make based build systems would generate the compiled files in-line with the source code.  Lately, ant based build systems would package all generated artifacts in a separate sub-tree off the root.  Regardless of your build tool, it’s best to have all generated artifacts in their own tree – it makes it easier to exclude as well as safer to clean!

In practice I see both patterns in use and both have equal merit depending simply on the situation at hand.  Option #1 is commonly used when generated artifacts are not to be included in the official release.  For example, transient or secondary artifacts such as test cases, debugging output, reports, etc.  These files are not promoted up to the release stream.  Option #2 is usually used when the generated artifacts are expected to be included in the official release snapshot.  Thus, they are promoted up through the test/build/release streams.  The build system for these types of ‘uber’ configurations may have multiple release targets creating different levels of release packages such as ‘minimal’, ‘app’ , ‘app-with-tests’ and ‘full’.  That is to say, the CM system may have all possible files but you can choose what actually gets deployed.  Ultimately, storing everything in the CM system may likely be the right choice for audit and reproducibility.

/Happy Coding/

The always informative Brad Appleton has a post on Software Agility which defines some fascinating terminology right out of Yogi Maharishi’s mantra.

How can you not love a process that includes:

• Sense the Problem/Opportunity
• See the Problem in the Context of the “Whole”
• Socialize the Goals and Constraints
• Swarm the Solution
• Show the Results
• Share the Knowledge Learned
• Life Goes on Within You and Without You

[Ok, I admit I added the last one from The Beatles, not Brad Appleton.]

I don’t really know what “Swarm the Solution” means, or “See the Problem in the Context of the Whole”, and I’m the poor dumb bastard that actually read the post.

The biggest challenge with “Agility” or “Agile” is one you can learn from the taxi business: if you don’t know where they want to go, it’s hard to get the passengers to pay you for taking them there.

Having run an Agile (Scrum) process here for almost two years, and having almost 100 Agile customers, there’re three things you need to know about Agile development before you can get it right:

1. Figuring out what to do next is the hardest part.  Kudos to those organizations who have a single customer they need to satisfy, but most of us have to make sense of often contradictory feedback coming from many sources.  Agile doesn’t make this easier.  It may, however, make your mistakes more like scratching a parked car than bouncing off a road grader.  Beware the process that can’t trace it’s stories back to actual customer statements!  Beware!

2. Time boxing means you have to spend the energy testing that you always told your mother you were going to do, but never quite go around to it.  If you start getting all soft on those developers and letting them make excuses for why it can’t be verified in the time box, you’re going to be in Faux Agile land, an evil place where developers run amok, dates come and go without meaningful results, and customers wander off for lack of adult supervision. Joel Spolsky wrote about Netscape entering this land many years ago.  I read it in my Chrome browser.

3. Self-Managed Teams can save you a lot of money by increasing your management branching-factor.  But don’t let the inmates run the asylum: people still go through bad marriages, get mad at their co-workers, and generally screw up, just like they did before.  The larger the team, the more likely your average team member is to be no smarter than the beer drinking, C+ grading, problem set copying, frat brother who peed on your car last night.  Management still has to provide the whack on the head needed to keep the good ones motivated and the bad ones headed to someone else’s frat party.

“Agility” is about getting somewhere faster.  If your process doesn’t get you going the right way, your doing Agile for No Apparent Reason.

Lorne Cooper

Brad Appleton’s series of posts on What Is Agility? bring up the right questions, but they don’t dive into the muck, like a BBQ eater in a white suit.  Muck diving is right up my alley, as the stuff I find interesting is usually at the bottom of the pile.

There are several fundamental problems to be solved, but the most interesting, by which I mean really hard, problem is understanding what is the most important thing to do next.

In The Agility Cycle, Brad quotes a host of luminaries, including himself, in defining what that thing is.   I like Gartner’s the best, and here I’ll have to quote Brad, as Gartner won’t let me read their original:

1. Sense the need for change in the environment (includes the proactive initiation of change)
2. Strategize the available options and develop alternatives
3. Decide which path to take and commit to the approach
4. Communicate internally and externally to everyone who needs to know
5. Act to produce results and follow-through efficiently

1. Sensing the Need for Change in the Environment

Let’s start with “Sense the need for change in the environment”.  Beware of management aphorisms that sound like something you’d hear at a Yoga workshop!

Not only is it hard to tell what the need for change is, it’s as hard to agree on it as it is to get two people to agree to toppings on a pizza.  By the time your company has it’s second employee, you’re in trouble.  When you get your second customer, it’s pretty much over.

Practically speaking, there are four avenues in which we business people “Sense the need for change in the environment”:

1. Strategic Pressure.  “The future is in Cloud Computing on the i-Phone.  Get me there in six months.”  Most engineering organizations are willing to set fire to the old application and do a little resume polishing on the new one.  Nothing like starting from scratch, unless you actually want to make money.

2. Competitive Pressure.  “Your App needs to do foobar, just like that other app does.”  Now that’s going to happen every day after you ship version 0.9.  It’s unlikely that any one request requires real change, but maybe that sound you hear is an out of control semi, and it might be nice to change direction before slamming into the grill of the truck.

3. Customer Pressure.  “I’m not loading any more of your crappy releases until the .2 version, at least.”  Hey, you Windows XP users, you know who you are.  And who I am.

4. Financial Pressure.  Sales drop.  New Account sales drop.  The CFO takes away our CapEx budget.  We have to reduce headcount [or "Free people to pursue other opportunities" as they say in Hollywood], reduce hours, reduce pay.  Doesn’t take a highly developed set of Senses to know things have changed.  But what do we do about it?

It’s relatively easy to deal with Strategic Pressure: unless the pressure is coming from your CEO’s who’s an ex-Marine Karate instructor with a Meth habit: slow down amigo, and study it. Engineering is a discipline where things take time.  The worst thing we can do is change priorities faster than we can get them to market.  Change needs to require a good case.

Market of any size don’t have windows that  close in six months.  More likely people will learn that Prolog wasn’t really all that valuable, or you could like without a MS-Bob plug-in.  SOAs and the ASP business model have been around for ten years.  Before you imagine yourself as the next “i-Fart” author, ask yourself, what percentage of the apps on the i-Phone have made over $100K in revenue?

Competitive Pressure and Customer Pressure are not the same.  Competitive pressure shows up when your organization is losing business to a competitor.  Real Customer Pressure is when you can’t live up to your value proposition without making changes.  These two are the realm of Product Management.

The difference between a great product manager and all the rest is whether they can determine which customer or sales requests require change, versus the ones that go to triage and get prioritized with all the others.  Signals that you might have to really change what you’re doing are when you get demands for 10x performance improvements, or to support workflows that just don’t fit.  Patches (”now 30% faster!”) just aren’t going to make those requirements go away.  Now you’re going to have to think about how to address a new market environment.

Finally, Financial Pressure is the easiest to sense, and the least likely to activate change.  Financial Pressure tends to make organizations to freeze up.  Whether the reason was lack of product competitiveness, global recession, or a controller with a cocaine problem, the result is the same competitive and customer pressure, fewer resources to deal with it, and (unless you’ve been investing in those employee meditation session) lower morale.

Two mistakes managers typically make: trying to use the same development process, and freezing CapEx.

Improving the development process is your way out of this mess, not something you can’t afford to do.  That’s like the teenager who knows he’s going the wrong way, so he drives faster.  And, if you have the cash (or if the government is giving it out like candy on Halloween), Capital Expenditure is the cheapest way to get onto a better process.

Lorne Cooper

by Rob Mohr

Do you have the “Admin Trigger” installed and running in your AccuRev environment?  I hope so!

The “Admin Trigger” is the best way for you to restrict those non-ACE’d (AccuRev Certified Engineer) users from wreaking havoc on the process you’ve meticulously designed and implemented for your organization.  Make sure you lock it down!  It’s really simple to do!

Now, I’m not talking about taking flexibility away from your developers, they’ll need to control certain aspects of the process too.  It’s up to you where the line is drawn in the stream hierarchy and the Admin Trigger is the chalk.

The equator is commonly established on the integration stream.  Since the globe in this case is AccuRev, the line of demarcation runs north and south.  To the West (upstream from integration), ACE’rs set the rules on workflow, code promotion, stream configurations, and general access control.  To the East (downstream from integration), developers and development teams are free to make their own decisions to best support their process, products, projects, components, patches, bug fixing and development activities.

Have you read the private prototyping or stream-per-task blogs by Dave Thomas?  These are good examples of how dev teams and developers control how their activities are organized using streams while adhering to the overall enterprise software development life cycle (SDLC).

The Admin Trigger is a simple if-then-else perl script that fires on the server whenever certain commands are  executed.  Out-of-the-box, the script restricts “admin type” commands such as creating users, groups, depots, etc without needing additional customization.

 @cmdlist = qw/mkuser chref chdepot chslice lsacl addmember
                  rmmember mkgroup mkdepot mktrig rmtrig
                  setacl write_schema/;
    # is the user command in the above list?
    if (grep $_ eq $command, @cmdlist) {
    ...

The admin type commands are typically global in nature, meaning, that a single Admin group is granted permission for these commands.  Stream creation has a more granular scope allowing different groups to control their development process and stream management capabilities.

Simply list the streams in the trigger that only Admins have the ability to “manage.”  By default, other streams not listed are managed by the development teams themselves.  There are 2 sections in the trigger to set this up depending upon the commands to control.

Restricts: lock, unlock, chstream, incl, excl, incldo

    $admin_stream{"replace_with_admin_stream"} = 1;
    $admin_stream{"replace_with_admin_stream"} = 1;
    $admin_stream{"replace_with_admin_stream"} = 1;
    ...

Restricts: mkstream, mkws

    $basis_stream_deny{"replace_with_basis_stream_to_deny"} = 1;
    $basis_stream_deny{"replace_with_basis_stream_to_deny"} = 1;
    $basis_stream_deny{"replace_with_basis_stream_to_deny"} = 1;
    ...

Inside the trigger logic, each command is evaluated and will allow the operation to complete or not.

For example, the following section validates the “mkstream” command:

if ($command eq "mkstream") {
...
 # only a user listed as an administrator can create a new stream
 # based on an existing stream in the "basis_stream_deny" list
 if ( defined($basis_stream_deny{$stream2}) and `$::AccuRev ismember $principal "$admingrp"` == 0 ) {
   print TIO "Basing a new stream on existing stream '$stream2' disallowed:\n";
   print TIO "server_admin_trig: You are not in the $admingrp group.\n";
   close TIO;
   exit(1);
  }
}

There are other facilities in AccuRev to control the process and workflow too. Stream Locks grant users/groups the ability to promote to and from streams and Access Control Lists (ACLs) grant access to entire depots and subhierarchies.  Setting up these security measures combined with the Admin Trigger provide your organization with the flexible and granular security model it needs for the optimum development process.

Drop me a note and let me know the creative ways you’re using the Server Admin Trigger.

As organizations become more advanced in their use of software configuration managment (SCM) they typically expand its use to include more than the software developers.  A common addition is around audibility and compliance of the entire development process which may require them to version more than just the source code, but also any requirements, project plans, design artifacts and documentation.  This enables the labeling of the big picture of who, what, where, why and how the software was developed.

With this expansion there are now more users of the SCM tools, many of whom have never used a version control solution before. A few examples of these new user types may be hardware designers, graphic designers, product managers, or the documentation team. These types of users are working with different types of files, and work in different tools than the traditional software developers and because of that may use version control tools in different ways.  These users may have historically created versions of files using naming convention such as:

 ReleaseNotes_v1.doc, ReleaseNotes_v2.doc etc. all on their local computer.  

Obviously this can be an error prone process and also a single point of failure if something were to happen to that user’s computer.  Since many of the files they work on are binary (.doc, .pdf, .ai, .dwg, .vsd etc.) they may want to work on these files in a serial mode so they don’t have to try to manually merge them when someone else makes changes to them in parallel.  So instead of the traditional use of AccuRev, taking advantage of our parallel development features, these users may want to work in exclusively locked workspaces or at least have exclusive locks on certain files to protect them.

In order to make this new type of user successful they need to use an interface that is familiar to them. With many source code control tools they may have to write scripts, manage configurations or interact with a command line interface to be able to get their work done. This type of interaction will likely not work well for these types of users, as many of them may not have the technical know how to work in those environments.  AccuRev can make this transition much more fluid and familiar for these users with the AccuBridge for Windows Explorer. This interface gives the user access to the AccuRev commands needed from within the familiarity of Windows Explorer as seen in exhibit 1.

AccuBridge for Windows Explorer

This interface gives the user the access to the AccuRev commands that allow them to open the files in the tool of their choice to make changes, keep, promote and revert those changes, create and update workspaces, view the statuses of files, AccuRev version information and lock types for the files, search for changed files within the workspace and view history. Even, if desired, create change packages associated with issues for the promotions just like the software development organization.  This coupled with the traditional Windows Explorer fields and views give the users a variety of different ways to view and interact with the files such as choose thumbnails view, which can be helpful for these users to see an image of the contents as seen in exhibit 2.

Thumbnails view with Windows generated images

It is with the use of AccuRev with the AccuBridge for Windows Explorer that I have seen the fastest and widest adoption of version control to groups unfamiliar with version control across organizations. Both the organizations and end users have seen tremendous benefits from having this information readily available in the version controlled repository, and I have seen this implemented all in a single depot with streams that separate out these items from the source code or some have opted for completely separate repositories.  I prefer to have them in a single repository separated by streams because it gives you the ability to include these artifacts in snapshots with the source. In addition to the ease of adoption for new AccuRev users, the AccuBridge for Windows Explorer can also benefit the current users both indirectly and directly.  Indirectly they benefit form knowing where to always find the latest and greatest files from the designers and product managers to ensure they are working off of the most up to date specifications.  Directly they too can use the AccuBridge for Windows Explorer as an alternative to the IDE integrations, command line or AccuRev StreamBrowser.  This can be of particular help when editing files in the non-standard editors by using the ‘Open With…’  and then having the abililty to keep the changes without having to jump between interfaces.

 All in all the AccuBridge for Windows Explorer can be an easy way to incorporate the non-source artifacts into the release process  for compliance, as well as another way for the software developer to interact with AccuRev.

by Brad Hart

In just about every situation in the last 8 years where I’ve gone into a prospect to talk about replacing ClearCase, I’ve been asked the question about ClearCase’s Dynamic Views and why AccuRev does not have a similar concept. It’s a fair question coming from those who are familiar with ClearCase and I’m posting this blog to help both give some background information on Dynamic Views and answer some of the common issues raised by former users of ClearCase before they made the switch to AccuRev. I used to work at Rational Software in both Support and in the Field and I spent a number of years as a ClearCase consultant before coming to AccuRev in 2001.

At the time Dynamic views were introduced, there was tremendous pain in the market using a local source copy model, especially in enterprise applications. Disk space was extremely expensive, and it was becoming increasingly infeasible to have large enough disks on each developer’s workstation. Networks were also much slower, and the time required to copy entire sets of source code to each developer’s workstation was unrealistic as applications grew in size and complexity. Dynamic views provided the appearance of each developer having a local copy of the source files, but without the time / disk space overhead associated with having real local copies. They also provided just-in-time access to files across a network connection which was transparent to the end user, similar to the way NFS works. Unlike NFS, which you only can access the latest version of files, the dynamic views allow the developer to reconfigure their view of the files to represent any given configuration past or present. Also, unlike a local copy model, reconfiguring what a developer sees does not require any file copying to reflect the changes. This saves time and money and the savings continue to scale the larger the development group gets.

Does it still hold water?
No. Both workstation and network hardware costs have dramatically dropped in recent years, and the performance has increased exponentially. It is very common and reasonable for developers to have near server-class systems on their desktops. In many cases, it is now a much better time savings to have developers work with local copies of their source files. In fact, Rational’s default usage model for developers is to do their development in a local copy source file model, contradicting the presence of Dynamic views. Dynamic views were a time and cost savings breakthrough when it was introduced, but given the changes in development environments in the current time, it is more often than not seen as a hindrance. There is also a much higher administrative burden associated with Dynamic views. Especially if you are working in a mixed environment (SAMBA, TAS, etc… need to be properly configured and maintained). Also, Dynamic views are notoriously unreliable and unusable over remote connections. Another major objection to Dynamic views from the developer perspective is that most developers don’t want “the rug pulled out from under them.” Your files are constantly changing in your view….how are you supposed to develop/build and test like that? Add in the fact that ClearCase does not have atomic transactions, and developers using Dynamic views will constantly have inconsistent sets of code to work on. Bottom line is that even Rational recommends developers use Snapshot views (like AccuRev workspaces) and only use the Dynamic views for integrations. Since AccuRev truly builds in parallel development, you don’t need an integration view/workspace. All your work can be done directly from one workspace.

Five things I’ve heard from developers on why they think dynamic views are important to an effective development environment:

WYSIWYG: The final test of your code changes before check-in is exactly the same thing as testing the release area code directly. No need to “check it out again in a different place just to make sure I checked in everything right.”

AccuRev allows your private work (keeps) and your check-ins (promote) to all occur from the same place (you don’t have to check out to a different place). AccuRev builds in best-practices like private-branching (workspace streams), atomic transactions, and copy-merge. You don’t get that out of the box with ClearCase. AccuRev’s built-in best practices absolutely improve the entire process. You absolutely must merge against the latest code before you promote your changes (for overlapped files). Plus, developers have total control of their workspace bringing in new changes as they are ready. That way if something is broken, they will know whether it is their code, or the latest code from the mainline. With Dynamic views, you will have to go find out for yourself and it is constantly changing. I have heard a lot of the “rug being pulled out from under me” analogies regarding dynamic views.

Zero-latency perfect synchronization with the release area: no time is ever spent checking out all the files in the entire directory just to see the release area. You are always “seeing” the release area. Your code is the release area.

Running updates in AccuRev is trivial and incremental. Performance far exceeds ClearCase’s snapshot views. You don’t need to check out all the files. Updates just bring in the changes.

Instantaneous creation of a new view into the release area: Suppose you want to do a quick mod and test of the release area code. Just create a new view, make the code mod, and do a build. You are good to go. No time spent doing a full checkout of everything just to modify 1 line of code in 1 file.

With AccuRev, you can simply re-parent one of your workspaces, update, check in your changes…done.

Automatic synchronization with the continuous development of code in the release area. Suppose you have a huge pile of code checked out for 3 weeks, and one week into it somebody checked in a change that broke your implementation. Dynamic views force you to reconcile the merge difference the moment the file is checked in, while it is still fresh in everybody’s mind. No trying to recreate the scenario 2 weeks later because you forgot to do a refresh of your sandbox. Your build will immediately fail, and you can confront the guilty party before they go on to work on other stuff. With dynamic views, the team is always in alignment and working on the code together.

Too much thrashing. This might work for a very small team. This would be mayhem for a large group.

Entire directories can be rearranged without worrying about somebody’s checkout becoming unmanageable. Since everyone instantly adopts all the changes that take place in the release area, all the files in a directory can be moved and changed without you even being aware of it. All of your “checked out sandboxes” instantly are updated to work with the new directory structure. This freedom encourages engineers to create a well structured file hierarchy, even making changes during critical bugfix periods in a product development cycle a non-issue. One does not feel the need to keep around old sandboxes “just in case everything breaks.”

Absolutely no problem for AccuRev. AccuRev has true namespace versioning and handles all elements using element ids. You can work on a file and have someone else rename it and it will cause you no problems at all. When you update, the file will be moved to the correct location and your changes will remain in effect.

This post is not meant to discredit the work done by the ClearCase development team, but rather to point out how Dynamic views have all but become obsolete. The VCR changed home entertainment forever…but you’d have to pull my DVR and DVD players from my cold dead fingers while my VCR is nothing but a fond memory collecting dust in the basement.

What are your thoughts?

-Brad

AccuRev CTO, Damon Poole, is a guest speaker for an Agile webinar series, Agile 101: Laying the Foundation for Agile Development, presented by VersionOne.

Damon will be presenting this Wednesday on the following topic, and again on April 1 to discuss The Algorithms and Architecture of Agile vs. Traditional Software Development.

Breaking the Major Release Habit
March 11th
12:00 – 1:00pm EST

Are you frustrated with your release schedule? Are you considering moving to more frequent releases or wondering if there are ways to tweak your release schedule? Although the traditional pattern for software releases is to have a major release every 6-12 months or more and minor releases in between, there are many other release patterns to choose from. This session will examine the various factors and options involved, discuss their pros and cons, use examples drawn from a wide variety of companies, and give you the information you need to make an informed choice and then implement it.

Register