AccuRev released for general availability today the first Git integration that seamlessly bridges the world of commercial tools and open source software configuration management.

AccuRev’s Kando, an enterprise security and compliance platform for Git, which was released in beta in January, complements the open source SCM tool with additional functionality, allowing organizations using Git to simultaneously leverage enterprise-level security and requirements traceability.

Kando is the first software development solution that enables Git development shops to add workflow, issue tracking, security, change requirements and other capabilities to the software development process, all while maintaining the flexibility and familiarity of Git environments.

Kando’s ground-breaking enterprise-level security and compliance capabilities allow its users to:

• Comply with enterprise-level regulations, by providing full audit and traceability
• Secure Git with access control capabilities, and support for enterprise authentication via LDAP and Microsoft Active Directory
• Visualize and manage development processes that use Git in AccuRev’s StreamBrowser™ environment
• Support Software Change and Configuration Management (SCCM) through change-based development with AccuRev Change Packages

“Our Kando Beta announcement in January had an overwhelmingly positive response, and it is clear that Git adoption has expanded well beyond the Linux community, into product development and IT,” said Lorne Cooper, AccuRev’s CEO. “Kando can solve many security and requirements traceability problems that enterprise organizations face when adopting Git, and really allows Git an opportunity to scale the development process across enterprise software development teams.”

During the development of Kando, AccuRev established the Kando Technical Advisory Board, comprised of representatives from several enterprise organizations with Git environments. To hear what they are saying, or to learn more about Kando, visit http://www.accurev.com/kando.

The secret’s out – AccuRev is releasing a seamless security and compliance related solution for the Git community called Kando on January 31st. To get a first look at Kando, register here for the webinar on 1/31/2012, at 1:00 PM EST.

You might be asking yourself, “Why in the world would a company focused on providing software development tools to enterprise organizations with mission-critical software development environments produce a solution for an open source version control tool?” I’ll tell you!

Git is increasing in popularity among developers working in small groups or collaborating on open source projects. It’s fast, flexible, and full of developer-friendly features. Git is a great tool for these smaller and more social types of development projects, and based on discussions about Git with customers, prospects, and analysts, it’s clear that there are more cases of enterprise organizations trying to use Git.

But poke around a few blogs, or read a few articles that discuss the use of Git in an enterprise environment, and I’m sorry, but you will uncover a few issues. As one article in BCW discussed, “Git is a version control system with an attitude of collaboration and sharing. There is practically no way you can enforce a specific pattern of access and sharing. If the people who’re using Git don’t want to follow your rules, the tool is not going to help you much.” Let’s be realistic – Linus didn’t originally design Git for use in an enterprise environment!

So, in which cases do enterprise organizations actually use Git?

1. Android Development

If you want to make changes to Android, you’re going to need Git. It’s unavoidable. This means any company creating mobile devices running on Android and working with Android source files has a real business need to use Git.

2. Linux Development

Same as with Android, if your company has a need to make changes to the the Linux kernel, you are going to need Git. Even if you don’t use Git when making those changes, you’ll eventually have to get them into Git.

3. Working with 3rd Party Vendors or Outsourced Teams Using Git

Similar to the Android and Linux situation, if you’re working with 3rd party vendors or outsourced teams who require that you merge your changes into their Git repository, you may be forced to use scripts or bridges to get your changes from your SCM into Git or vice versa, and that’s not a small task.

4. All of Your Developers Love Git

Let’s face it – Git has a cult-like following in the development community. Developers love Git because it’s fast, distributed, flexible, fairly easy to learn, and has a ton of developer-friendly features. It’s developed by developers for developers. Even if you understand the issues Git has with scaling in enterprise environments, it’s difficult to avoid Git when lots of your developers are pushing you to switch.

The enterprise software development arena can be a harsh and unrelenting environment – not a place for the faint-of-heart to work. Fortunately, software configuration management (SCM) software can make it not only more tolerable, but more efficient and, yes, even more successful.

SCM software is not a luxury, nor just another layer of technology to be added to an already complex process. SCM software is a necessity for development teams working concurrently and in parallel on development projects, especially those employing agile processes to deliver higher quality software more rapidly.

Two of the biggest benefits of using SCM software are the ability to coordinate distributed teams and parallel development more effectively, no matter where your team members are located or even the language of the replicas being used – they can be in the next cubicle, the next state, or the next country.

We, of course, recommend AccuRev SCM

No surprise there. After all, we designed it to be fast, flexible, scalable, and effective. After all, we’ve taken process management and version control and made the ideal mash-up that provides the most comprehensive set of SCM tools available, including these best practices:

• Change management
• Visualized SCM patterns
• Automated workflows
• Private developer history
• Multi-stage continuous integration
• Issue-based development

With a single set of comprehensive, best-practices SCM tools to work with, life becomes much easier for your development teams – they can focus on software development instead of management and administration tasks. SCM software made nice and simple.

What makes it even easier is how AccuRev SCM easily handles virtually any combination of development processes, including Agile, XP, and waterfall – you name it. You’re free to mix-and-match because AccuRev SCM’s flexible model enables your teams to rip through development with continuous integration, code refactoring, and automated code sharing, to name a few.

Even parallel development is a cinch with fully-transparent code base relationship management that enables teams to store work safely and test it before sharing it with others. A stream-based architecture makes code branching and merging easier, too – it even allows changes to be automatically inherited from other teams.

If for some reason you’re not already using SCM software or if you’re unhappy with whatever software configuration management tool you’re using now and you want to know more about SCM software and AccuRev SCM in particular, check out our SCM Software Resource Center and AccuRev SCM 5.3.

Did you know that CM systems back in the day were basically people? This is where the term “check-in” & “check-out” comes from- it refers to the days when there where actual software librarians would record peoples changes and check them in and out like books on disk or punch cards. It’s mind boggling to think of software this way.

If I was to ask software developers today what “software configuration management” was, they would probably say “SCM? Like Subversion?” Incorrect! You need to trust me on this one, SCM is not the same as a version control system. Yes, your version control system is an SCM tool (confusing?) but SCM is a broader discipline and technique that encompasses the management of change in software.

The introduction to the IEEE “Standard for Software Configuration begins with:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

• Providing a structure for identifying and controlling documentation, code, interfaces, and databases to support all life cycle phases
• Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy
• Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Let’s be clear- all of the things on this list do not fit under the heading of your version control system. Many of them will require practices and policies to maximize your development efforts and methodologies. With version control, release engineers will still have to perform some of these SCM related functions:

• Merge early and often
• Enforce a workflow for development teams to follow
• Record and have full visibility into all of the changes that were made
• Write build and compiler scripts
• Automate builds, deploys and tests
• Understand the dependencies between projects and code
• Maintain the development environment for a team
• Be responsible for the final product going out the door

That’s just the tip of the iceberg. A talented release engineer or SCM expert can do all of those things independently, but his or her job would be a lot easier with SCM tools that can automate and facilitate the necessary practices and processes. (This includes version control, compilers, debuggers, editors, continuous integration machines, automated deploy, and the ITS system.)

At it’s core, SCM answers the question “Somebody did something, how can one reproduce it?” In addition it’s about understanding and establishing relationships among items that are likely to change. It’s a tricky job, not one that’s easily understood. We have to understand the relationships between versioned artifacts, like code, hardware, documents, design models and even directory structures. In addition we have to do all of the necessary things to make those versions valuable to our organization. We have to design process, workflow, automation, build automation, reports and security.

With all of this, don’t tell me that SCM is the same as version control. Trust me on this one!

The holidays are still several months away, but for software development teams in the travel industry, the “hustle and bustle” of the season is already here.

If you think about the ways you make your business or personal travel plans today, you’ll begin to appreciate the increasingly complex software development challenges travel websites present – and the importance of advanced SCM tools.

Just 10 or 15 years ago, many of us were still making travel arrangements through an agent – on the phone or in-person.  We may have gone online to check out a hotel and moved to another site to check on flights – and yet another to rent a car.

Today, travel websites like Kayak and Orbitz bring together all these consumer options and more – and others include frequent flyer miles, preferred guest points and other information related to our travel plans, often involving outside partners.  All of these variables are changing rapidly and are updated dynamically and in real time on travel websites.  This places greater demands on software development teams – teams that are increasingly distributed across multiple time zones and locations.

Also important to note is that the changes and updates these teams are called on to make are increasingly “business-critical.” A software glitch or a site crash can result in major revenue losses, not to mention the residual consumer frustration and damage to the brand.

More variables, more frequent updates and a more business-critical focus — now magnify all this during the many times of peak travel or weather-related interruptions and one begins to understand why more advanced SCM tools are required in the travel industry today.

Basic software development tools may have been fine for some organizations in travel — smaller airlines or hotels with more basic informational web sites that aren’t designed to process high volume reservations and transactions.  But such basic sites are becoming a rarity in the travel industry, leading more and more travel and hospitality businesses to turn to more advanced software development solutions.

AccuRev’s SCM solutions are designed to handle today’s most complex software development challenges, which explains the growth we’re seeing in travel and hospitality business customers.

So when the holidays draw near and you go online to book a hotel, schedule a flight or rent a car, you can thank all of those software developers that have been working hard behind the scenes to make sure the site is up and running 24/7.

If you scratch any software configuration management (SCM) system hard enough, what you’ll really find is a source control system. In reality, SCM and source control are basically one and the same. Having truly effective SCM is all about having good source control.

The challenge today for any software developer is the rapid pace and simultaneous development that has dramatically changed the development landscape over the past few years. Throw in the latest Agile development processes, mix in some more traditional methodologies, including XP and waterfall, and now you’ve got a real witches’ brew of development activity that can put a strain on source control.

One of the reasons we’ve developed AccuRev SCM is to provide a sound source control system. Something that enables distributed teams to communicate, collaborate, and integrate code as seamlessly and effortlessly as possible while providing full transparency to all source file changes.

So what exactly are the benefits of a source control system? Here are some main ones:

• Source control enables multiple development teams to access and share code simultaneously, enabling effective parallel development
• It enables code to be managed and protected to help ensure file integrity
• It provides a way to label, or version, a chunk of code — even whole sets of code — so that a complete file history can be maintained for faster, more effective development and revision
• It helps with change management so that new software versions or added functionality can be tracked and approved

As a source control system, AccuRev SCM really helps developers by providing process visualization, drag-and-drop SCM automation and issue-based workflow using something we call “streams” – a type of architecture that’s a sort of “intelligent” branching. This type of architecture provides outstanding source control because each stream contains every file for a specific source code configuration. This, in turn, makes branching and merging easier, even in a distributed, parallel development environment. This streamlined architecture enables teams to store their work and test it before sharing it so that merging code becomes a lot easier and safer.

With a good source control system, you’re able to accomplish some pretty amazing stuff. We’ve found that AccuRev SCM can:

• Improve Agile/hybrid process project collaboration
• Improve software asset reuse
• Accelerate time to market
• Lower total cost of ownership
• Accelerate the software development process by 30%

Efficient, optimized software development starts with solid SCM, and that means a good source control system.

There are a handful of SCM best practices that can optimize continuous integration.  This post will look at:

• Establishing a staging and isolation hierarchy
• Automating builds at all stages in the hierarchy

Establishing a staging and isolation hierarchy for optimizing Continuous Integration

Proponents of continuous integration commonly suggest branching as little as possible and having developers work directly from the mainline as much as possible. However, this approach has several difficulties:

• It puts the stability of the mainline at risk
• It presupposes that traditional legacy branches are the only available isolation mechanism
• It decreases the flexibility and agility required for fast iterative development

With modern SCM systems, a better approach is to implement a staging and isolation hierarchy for the development process. A staging and isolation hierarchy uses objects in the SCM system to represent the dependencies between development groups and process steps. For example, you may wish to model the following teams and activities:

• Release engineering
• Quality assurance
• Product engineering
• Component engineering

Each team or activity is assigned the equivalent of a private workspace (variously called “streams” or “branches” depending on the SCM system). Each team then receives the same benefits of private workspaces that individual developers receive.  With a staging hierarchy, changes move from less stable configurations to more stable as they are tested and deemed “good” for the next level. This allows the code to be stabilized as it gets ready for release without developer downtime. It also allows additional separation for each team if needed, so that the team’s changes can be integrated and tested before the components are integrated together.

In this figure, there are four development teams as well as an area for accepting third-party code drops.  The teams are located in different geographical areas. The hierarchy represents the normal flow of changes through development from stage to stage. In the example of the above figure, changes provided by the GUI product engineering team in India flow from individual developer workspaces (not shown for brevity) to the GUI stage, where they can be continuously integrated and tested. Mature changes then flow to the UI_int stage and on to the QA and Release (Rel) stages, again being subject to continuous integration and testing at each stage. The web development team in Austin picks up well-tested changes from the UI_int stage and uses them as the basis of their development work; when the web changes are mature they can be pushed up the hierarchy and subject to broader testing in the UI_int, QA and Rel stages.

Using a development hierarchy provides more opportunities for check-pointing. Every change introduced into the system is a potential source of failure, and thus a potential checkpoint. If a change proves to be unstable, you can return both the source stage and the destination stage back to a previous checkpoint. By contrast, mainline development only offers you a single opportunity for check-pointing, specifically, the state of the main codeline itself. Unless your development process includes “freezing” the mainline for a long enough period to build, test and otherwise validate, the chances of isolating and check-pointing at an appropriately fine level of code granularity are slim, making any available checkpoints stale and of limited utility.

Automating builds at all stages in the hierarchy

In order to give developers prompt feedback about the changes submitted, the code must be built frequently, ideally several times per day. A continuous integration server such as CruiseControl, CruiseControl.NET or Draco.NET can be employed to automate this process. The continuous integration server periodically polls the SCM system for changes, populates the changes to the build server, initiates the build process, and reports the results of the build and unit tests.  It is important to note here that the continuous integration server utilizes the existing build scripts and build environment to execute the build. For example, if make is used to compile and link components written in C, then the continuous integration server will call the makefile to initiate the build process.  Because the continuous integration system uses the existing build, it is important for development groups to devote time and effort to:

• Making the build as fast as possible,
• Building automated unit tests and
• Including unit tests as part of the build process.

Spending time on these items, even if it involves some rework of the build system to make it more compatible with a continuous integration environment, will improve not only the build process but the overall quality of the software release.

When utilizing continuous integration, it is crucial to communicate the results of the builds to the entire development team. Continuous integration system planners should consider a scalable communications method such as e-mail notification or an internal website to display build results.

Continuous integration servers such as CruiseControl come with built-in web reporting that can be easily customized, so that build results can be displayed on LCD panels in common areas at geographically dispersed locations. In this way, team members can easily see and respond to the build results and reduce the “fix latency” often encountered with nightly or weekly integration build approaches.

There’s no denying that this has certainly been the Agile decade for the software development industry.  It’s evident all around us in this tenth year since the Agile Manifesto was created. Most companies and development organizations today have implemented some form or aspect of Agile methodology into their software development processes. Whether you’re aiming for pure Agile or a mixed/hybrid approach, proven best practices in all phases of the software development lifecycle are crucial to success.

This is especially true in the case of continuous integration, one of the foundational aspects of the Agile methodology. The concept of continuous integration, as defined by Martin Fowler, is “a fully automated and reproducible build, including testing, that runs many times a day.  This allows each developer to integrate daily, thus reducing integration problems.”

With this approach, developers can work more closely in parallel while identify problems and debugging on the fly, accelerating the development process and improving the quality of the finished product.  The benefits of continuous integration are tremendous, but can quickly be eradicated if software configuration management (SCM) best practices are not carefully followed.

There are a handful of SCM best practices that can optimize continuous integration.   Let’s start with a quick look at the first two:

• Using an SCM system to store and version all source code
• Utilizing private developer workspaces

Best Practice: Using an SCM System to Store and Version all Source Code

Parallel development and distributed software teams can make tracking changes a daunting task, especially with the frequent changes that occur when using continuous integration methods.

For this reason, it is important to employ a software configuration management (SCM) system to strictly version changes to the code base. In addition to versioning source code, everything needed to build the system should be placed under version control, including the following:

• Third-party libraries
• Properties files
• Database schema
• Test scripts
• Install scripts

All developers should have at least read-only access to all files needed for the build and should obtain all such files directly from the SCM system. This approach ensures that developers are working with the latest build environment, and is preferable to the common but error-prone practice of placing such files on a shared file server.

To effectively implement continuous integration, all development groups should work from the same central source code repository so that the latest changes from other developers are easily and immediately available.

Best Practice: Utilizing Private Developer Workspaces

In order to fully realize the benefits of continuous integration, software development organizations need to ensure that developers can remain productive regardless of the overall state and stability of the project source code. To achieve this, private workspaces that give developers full SCM capability should be used. Private workspaces enable developers to

• work in isolation
• revert to known “good” states when needed
• checkpoint their changes
• share only mature, well-tested code with other team members

The benefits of isolation are bidirectional—it protects developers from incoming changes, and protects the shared code configuration from incomplete or incorrect changes from any one developer. By creating private workspaces, developers receive all the benefits of SCM for their personal use, including the ability to revert to a previous state, viewing and tracking of changes between software configurations, and setting aside changes to begin work on a different task.

Once a new known good state is reached (for example, when a developer completes engineering and testing work on a feature), developers should checkpoint their work, typically by “checking in” or “keeping” the local changes in the SCM system. The checkpoint ensures that the developer’s work is safe on the SCM server and that the checkpoint can be revisited at any time. However, since the changes have not been shared, other developers and teams are not affected.

When a developer breaks isolation and decides to share a code change, he or she is essentially making an assertion that the change has reached a higher level of maturity. This, coupled with the use of local developer builds, helps to ensure that only mature, well-tested code is passed on to the rest of the development team, a primary benefit of continuous integration.

In the world of software development, or any product, for that matter, one of the things you may frequently be asked to do is to create a “special version” for a specific consumer.  This version might be almost identical to something you have already created, but with a few minor tweaks, or it might need to share some of the same core characteristics but have critical deviations in certain areas.

For software development – and the correspondingly essential Configuration Management of that software – I’ve seen how this can be one of the more challenging aspects of the job.  It’s not actually the creation of the “customer-special” that’s difficult though; in fact this is usually fairly trivial.  Traditional software configuration management, or SCM, systems use the branch-per-variant approach typically, and everyone knows that branching is easy.  The hard part comes when you need to manage that customer release in an ongoing fashion.  How do you upgrade them to a newer release of your product?  They probably won’t want to remain on their baseline version forever.  They’ll want to take advantage of new features and fixes, while still retaining their unique aspects.  So this brings you to… oh yeah, the actual _merge_ part!  That’s where it gets hard.  Reliably merging changes from one variant to another is a manual, error-prone, labor-intensive process.  Now I remember!  That’s why we try to limit branching.

Configuration Management with Customer Specials

Well, all of that messy, cumbersome, and problematic stuff in traditional configuration management systems utilizes a traditional architecture of branches.  Fortunately, you use AccuRev, which completely removes this obstruction and makes the management of customer specials not only easy, but elegant as well.  Let’s consider the following purely mythical scenario.  A company called ‘Stadiums’ that makes Ballparks for general use released Stadiums_Ballpark_2.0 a while back.  Stadiums had a customer who wanted a custom version of the Ballpark that had some significant differences.  For example, they had special contours to the outfield, a truly unique left-field wall, and a good old fashioned mechanical scoreboard.  Those were the changes that needed to be made which deviated from the core Ballpark.  So Stadiums made these changes in a dedicated stream, associated their work with issue records using AccuRev Change Packages, and cut the Stadiums_Ballpark_Fenway_1911 snapshot:

Fast forward a few years.  It’s been a while and there have been numerous advances in Stadiums’ technology.  Ballpark_4.0 has been released.  The Fenway people don’t want to purchase a brand new product, but they do want to upgrade. This is where it would get really complicated in a different configuration management tool. To boil it down, Stadiums would have to figure out what changes were made for Fenway back then, what changes have happened in their ongoing development, and intelligently merge these together.  They’d probably still want to maintain traceability and reproducibility of the “older” version of Fenway.  Some of the other tools out there make this near impossible, some slighly less onerous, but none of them make it simple.

Enter AccuRev.  Here’s what you do.  Drag the Stadiums_Ballpark_Fenway stream and drop it onto Stadiums_Ballpark_4.0.  That’s it, you’re almost done!  Because of Inheritance capabilities in AccuRev streams, all the content of Stadiums_Ballpark_4.0 will flow down into the _Fenway stream… except items that are in conflict.  Those items will be identified by AccuRev both visually and with status flags, and you will be able to deal with them quickly and appropriately.

In our example, Stadiums developer llucchino has worked on the greenMonster.wall file and replaced class Netting with class monsterSeats.  So this file automatically becomes (overlap) in the _Fenway stream and can be merged.  There are more teams in the league so the scoreboard.mechanical file has been updated to change various properties.  This also is in (overlap) status.  But the contours of the outfield haven’t been updated at all, so despite that file being a custom modification for _Fenway, AccuRev intelligently knows that it doesn’t even need to be merged.  All other new content was automatically inherited by the stream, and so literally nothing needs to be done by the development team.

It’s that simple.  You’re done, go ahead and release Stadiums_Ballpark_Fenway_2011.  Another happy customer and it didn’t set you back many man months.  Can your configuration management tool do this?

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.