Archive for the ‘SCM Resources’ category

Overcoming Resistance to Change by SCM

November 17th, 2009

We ran across the article “Overcoming Resistance to Change by SCM” by Ben Weatherall on CMCrossroads. The excerpts below exemplify the need for tools like AccuRev that support changing processes and Agile adoption. Ben Weatherall has kindly allowed us to re-post these excerpts so that we may share his insight with all our readers.

Excerpts from “Overcoming Resistance to Change by SCM”

By Ben Weatherall

“As an industry, SCM is conservative – we hold the corporate jewels in our hands and we are reluctant to let either processes, procedures or personnel have a chance to mess them up. In fact, when they do get messed up we tend to lose our jobs. Then along came Agile and the need to support it while maintaining both technical and professional integrity.”

“Some of the old versioning tools could not handle merges of codebases where one or more of them had been refactored, so many of us had to rapidly switch tools. This often required a lot of hidden work to get triggers, wrappers, interfaces, metrics data collection, etc. working with the new tools. At the same time, there was a push to use tools that supported such things as backlogs and user stories instead of “just” defects. It was often the case where a development organization would bring in their own tools and tell SCM to either use them or get out of the way.”

“All of a sudden SCMers had to start rolling out their own tools, integrations, customizations, etc. with a speed even greater than the typical Agile development organization. And with significantly less personnel. We now leveraged what we could of the Agile methodology. We did rapid prototyping knowing ahead of time that things would have to be completely redone at a future time. Our assumptions, ones that made sense at the time, was that once a branching/stream structure and new tracking tools were in place to support this new way of developing software, it would stabilize and we could catch up.”

“The end result of this is that SCM has to adapt and do so at a rate that would have been considered impossible just a few years ago. We must adapt technologically, but we have to maintain the core integrity of principals of SCM: identification, reproducibility and traceability. A typical development sprint team consists of 5 people of which at least one represents the Quality organization. A typical SCM “team” consists of only one person. Across the software development industry as a whole, the SCM headcount is probably only 1-2% of the combined Development and Quality “workers.” For those of you in larger companies or those who are involved in admin-heavy tools, this probably sounds low; but from empirical evidence it is not. This is especially troubling for those who have to support multiple teams who are using different methodologies or variants of them.”

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis supporting a modified Agile-SCRUM development methodology. He uses a combination of AccuRev, CVS, Bugzilla and AnthillPro (as well as custom tools). He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), FWLUG (Fort Worth Linux Users Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).

For the entire version of this article on CM Crossroads, please visit: http://www.cmcrossroads.com/cm-journal-articles/13047

1 comment »

Posted in Agile, SCM Resources, version control

vim4accurev – New Release (v1.1)

October 2nd, 2009

I’m happy to announce that the latest official version of the AccuRev SCM plugin for Vim is now available!

Download release 1.1 here.

Major features include:

  • on-demand plugin enable/disable (aka Airplane Mode)
  • support annotate/blame
  • launching stream browser and graphical merge
  • ability to edit files and identify AccuRev workspace regardless of current working directory
  • updated docs

This version of the plugin requires Vim 7.x and supports AccuRev 4.6.x / 4.7.x.

Enjoy – dave

1 comment »

Posted in Customer Guest Blogs, SCM Resources

Tags:

Free Webinar: Emerging SCM Best Practices for Agile Development

February 3rd, 2009
More Agile resources

More Agile resources

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

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

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

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

Specific topics discussed will include:

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

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

No comments »

Posted in Agile, Events, SCM Resources

Tags:

Free Webinar: The Business Case for Pragmatic ALM – Agility with Governance

December 1st, 2008

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

As more and more software development teams adopt Agile or other iterative processes it becomes difficult for them to reconcile the current state of their governance practices with a need for greater speed and improved productivity. Developers get frustrated with overbearing compliance regimens that fence them in and stifle creativity, while their managers struggle with the need to balance innovation and speed with predictability and control. In today’s market environment, eliminating waste and fast implementations that demonstrate value quickly are essential.

Join experts from AccuRev and special guest Forrester Senior Analyst Jeffrey Hammond, as they examine the market trends that are driving many organizations to reassess their software development and release processes, and what steps and tools these development teams are taking to best support heterogeneous software development process environments. You will also see a live demonstration of how to implement pragmatic ALM with AccuRev.

Attend this Webinar and learn:

How Agile processes and compliance can coexist in harmony

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

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

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

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

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

No comments »

Posted in News, SCM Resources

Tags:

Right Process, Wrong Tool? Getting Ready for Agile

May 30th, 2008

Yesterday I was a panelist for a Webinar on agile tools, focusing on software configuration management (SCM), build and software process automation (SPA), the latter term referring to the set of defined, repeatable and measurable automated development workflows that engineers use to transform requirements into shippable software products. Contrary to what I’ve read about the disdain that some agile devotees have for tools, most of the attendees were hungry to know what features their SCM tool should have in order to support agile software development and SPA. Here are some of the highlights, and of course, my take on why I think AccuRev is the best tool for agile software process automation.

There are five key feature areas that an SCM tool needs to support in order to be ready for agile:

* Support for flexible process models

* Continuous integration support

* Support for issue-based development

* Efficient branch and code management

* Private version controlled developer workspaces

Let’s take a look at each of these in turn.

* Support for flexible process models. Agile is often one of several processes being employed within a software development organization. Unless your SCM tool is flexible and process-neutral, you will have a hard time implementing agile (say, for product development) and more traditional processes like waterfall (for example, for product maintenance work) in the same SCM tool. AccuRev streams are a natural way to model any process, and thus are a good fit when agile needs to coexist with other development processes. As for software process automation (SPA), AccuRev streams again are a great fit, since they enable users to model any arbitrary stages of code transformation that a development team sees fit to define as part of their process. By adding triggers and workflow to a stream hierarchy, teams can implement SPA directly in AccuRrev.

* Continuous integration support. Continuous integration is one of the core process elements associated with agile development. By building and testing frequently and acting on the results of tests, teams can uncover defects or test gaps earlier in their development cycle, saving time and money compared to such discoveries late in the cycle. But continuous integration goes beyond just testing the nightly build. With multi-stage continuous integration in AccuRev, code is automatically promoted up the stream hierarchy into more stable configurations as it passes tests. At each stage, continuous integration takes over to build and test, typically with a wider scope of testing as the code nears the release stage. Legacy SCM tools make this type of automated integration factory somewhere between difficult and impossible due to the complexity involved in setting up the hierarchy and in automatically moving and merging code as it flows up the hierarchy.

* Support for issue-based development. Apparently there is a lot of contention about the need for filing issues and defects in agile development. This has puzzled me greatly. While I’m in favor of developers identifying and fixing issues as they are discovered, you lose valuable process information when a defect or enhancement ticket is not filed and later associated with a code change. Without an issue that describes what the problem was, someone looking at the code changes for audit purposes or for group code reviews is at a disadvantage. Why was this code change made? Is it related to other changes? How long did it take? Was it done to fix a bug or to add a feature. In AccuRev, issues either in the integrated AccuWork issue tracking system, or in a 3rd party issue tracking system, can easily be associated with code changes via the AccuRev Change Package mechanism. This establishes basic traceability between issues and the code changes that developers make in order to satsify the requirements of those issues. Issue-based development is well-defined, repeatable and measurable – all hallmarks of good software process automation.

* Efficient branch and code management. Any time you’re working on more than one project, you need to isolate that project’s code from other projects. With agile and multistage continuous integration, even a single project requires multiple code lines in order to separate in-progress code from unit tested code from system tested code that is ready for release. If an SCM tool makes branching, merging and labeling difficult, teams tend to practice branch avoidance, which I sometimes like to call “fear of branching.” This is a classic example of letting a tool dictate what processes you can implement. In AccuRev, streams replace branches as the mechanism for isolating codelines. Since streams are represented inside of AccuRev as data separate from the actual file versions, creating streams is fast – really fast, like, a second or two – and managing a system with hundreds of streams spanning multiple projects and processes is easy.  For continuous integration, AccuRev snapshots and time-based streams are also fast and easy to create and manage, and give users a straight-forward way to “label” an interim or milestone codeline without having to place markers in thousands of source files.

* Private version controlled developer workspaces. Software developers are the heartbeat of any engineering organization. Executives at any development shop will tell you that hiring talented engineers and keeping them well-tooled and productive is the single largest challenge that they face. For agile, this is even more of a challenge, since coding cycles tend to be shorter, and thus anything that gets in the way of individual or team productivity tends to have a greater negative impact on the project. Private version controlled workspaces like the AccuRev workspace model improve productivity, since they enable developers to work in isolation (while they are ‘heads down’ coding). Private workspaces in AccuRev also give developers full SCM capabilites in their workspaces without the need to share in-progress code prematurely. By using the ‘keep’ operation, developers make safe copies of their work in the AccuRev repository, and later can ‘promote’ the code to an integration stream to combine their work with that of their teammates. Individuals are more productive in this way, and if continuous integration builds are frequently testing the integration stream, so are teams.

In a nutshell, agile requires tools, and these tools need to support different modes of operation than with other processes. SCM can help or hurt you in setting up and executing an agile process, so these guidelines are a way to help you get your SCM tool ready for agile - easy of course if your tool is already AccuRev!

If you’re interested, you can view the webinar recording.

Is Your Software Development Environment Agile-Ready?
Free On-Demand Webinar

4 comments »

Posted in Best Practices, SCM Resources

Tags:

Globally Distributed Developers, Under a Single Roof

May 7th, 2008

One of the most common and problematic challenges that exists in today’s software development environments is how best to support a Globally Distributed Development organization. In ye olden days, you had the entire team co-located in the proverbial cube farm under a single monolithic roof. If Brad wanted you to review the code he just wrote, he would literally turn around in his chair, ask you to come in and look over his shoulder.

Times have definitely changed. Now, your team might be headquartered in Boston, separate R&D sites in California and London, with some specialized groups in Bangalore and Shanghai. But that’s not necessarily the hard part. Where it gets complicated is when all these developers are trying to work on the same source code at the same time. Mastership issues questions, latency, mismatched process across sites; communication problems, lack of project visibility; these things all lead to significant decrease in productivity, not to mention the chaos for those trying to manage the effort.

Enter AccuRev. Uniquely architected to support remote and geographically distributed development (GDD), there are several key built-in capabilities that make the challenges of the past disappear. Consider the following graphic:

  • AccuRev’s Stream Browser presents a dynamic visual representation of the software development process that is both fundamentally tied to the source code itself as well as being flexible and enforceable. At a single glance, *anyone* working on the project anywhere knows exactly what the process in place is. (See example AccuRev annotated screen shot here from the Alaska Airlines success story).
  • Geography has zero impact on your position in the process; a developer in the UK can happily use a Workspace on the same parent stream as a developer in the United States. For low bandwidth locations, AccuReplica can provide LAN-quality access without introducing the traditional mastership and latency problems of other replication solutions.
  • The private nature of the Workspace means that these remote developers can “share” code while still determining when to deliver their changes publicly.

Here’s the scenario: Developer ibergman works out of London, while jtalbott works in Boston. However, they are both part of a virtual team working on ComponentC. With AccuRev, the normal boundaries and limitations of time and space – not to mention being constrained by an inadequate SCM tool – no longer apply. Okay, I took some verbal liberties with the “time and space” bit, but it’s actually not too far from the truth.

In London at noon, ibergman wraps up a section of code she’s been working on and performs a Keep, which in AccuRev is a private check-in. The change is versioned yet stays within the confines of the Workspace, not yet ready for public consumption. But ibergman wants some validation, and asks jtalbott to review her code. Using instant messaging (IM), she pings him and catches him as he’s having his first sip of coffee, probably a colombian supremo. In other tools, how would someone review a private change that was just committed on the other side of the ocean? Would they even have private commits in the first place? In AccuRev, the moment ibergman performed that Keep in London, a visual identifier is available to anyone viewing the StreamBrowser, such as to jtalbott in Boston. So jtalbott clicks on the icon, and now has immediate access to operations like View, to see the file, and Diff, to compare against any previous revision of this file:

Did I mention that jtalbott’s access to these operations is instantaneous, as soon as ibergman performs the Keep? He can even take her version and send it into his own workspace if he finds it interesting enough to want to do additional development on.

So the previously mentioned problems of mastership, latency, visibility, communication, and most importantly Process, have all gone away. No more waiting on a 24-hour turnaround to get that Shanghai code copied into the branch. No more working in the dark not knowing exactly where your piece of code fits into the puzzle. Each team can regain the responsibility of merging in their efforts into common integration points, using a well-defined process implemented with streams.

It’s a remarkably simple and elegant solution to a complex and challenging problem. Of course, it’s still not going to solve the amusing problem of both the London and Boston developers feeling like they are superior to each other, but at least now they can actually review each other’s code real-time to help figure that one out ;-)

No comments »

Posted in AccuRev, Agile, SCM Resources

Tags:

The Quest for Successful Parallel Development

May 1st, 2008

Read my earlier post: Fortune 500 Software Company Answers Your Questions on Using AccuRev

Up until fairly recently I had never worked anywhere that was able to do parallel development without it becoming a nightmare. Individual contributor or manager, we just seemed unable to find that secret magical incantation that would lead to a truly successful parallel development cycle.

Every time the team had a different plan, and the project’s champion would trumpet why this time ‘things would be different’. But in the end, we always failed in one of two areas (sometimes both):

  • The quality of the software suffered dramatically
  • We lost control of the schedule and we were forced to ship late

I actually worked on one project where the resulting release was so bad that a few weeks after release we had to pull the product off the shelves and work frantically to repair the damage.

Then a few years ago my team was looking for a new software configuration management tool to use. We started out wanting ClearCase, but after much deliberation, decided on Accurev. At first, we didn’t realize the power of the tool now in our control. But after a release or two, we started to realize what we had and adjusted our process accordingly and began to achieve very successful, high quality, and on time releases done in parallel with one another. We had found the holy grail of project management!

We started to understand not just what the best practices were with Accurev, but to understand what we were getting by following them. We made other changes to our processes that helped as well, but I give a lot of the credit to the tool-set for helping us in the right direction.

We started out performing a round-table series on our past projects, looking for common themes, and then choosing the top themes and seeing how we could use Accurev to solve them, and here are some of the things we found:

Problem: Often parallel projects require extensive code changes to the same files, leading to a need for developers to communicate what is being done to which files and when. Often this communication is not handled well.

Solution: Accurev’s work in progress and annotate commands, as well as the version browser allow developers to quickly view who else is making changes to the files that they care about, and what is being done to them. Now developers can pro-actively gather the information they need instead of depending on someone else remembering to tell them.

Problem: Often projects have late phase merge points which are both complicated and error prone. In addition since merging is generally done in the mainline, the entire release can be held when any two projects try to merge together.

Solution: By allowing stream definitions to be dynamic, Accurev allows developers to create common merge streams ad hoc at no cost, and to join the projects without effecting any other users. It also provides excellent trivial merge capabilities that save the users much of the error prone work, calling out only the non-obvious decision points which greatly simplifies the merge task.

Problem: Often bug fixes get made to one ongoing project, but developers forget to make the same fixes to other active lines of development.

Solution: Using change packages users can quickly make changes, move them to all appropriate locations, and quickly verify that the tasks were completed successfully. Using the stream inheritance feature minimizes the number of lines where a developer must make a fix for his coworkers to take advantage of it. This greatly lightens the load on developers and cuts down on the chance that something will be forgotten.

Problem: Ensuring 100% reproducibility of a build from pristine sources is a huge challenge. Changes to the build system environment, tools and code changes can all effect your ability to make a minor fix to released software.

Solution: By keeping your complete build system (environment, tools, sources) all in Accurev, and by using a snapshot you are able to guarantee 100% that what you try to build today is the same as what your built the day the snapshot was taken. Unlike a label, a snapshot is forever! This enables you to reduce the regression test matrix and focus on only the changes that developers make to the released software.

While I am sure that other SCM tools can offer similar results if you know where you are starting and know where you want to go. But what I marvel at is that using Accurev really lead us to the cup so that we could drink from it and enjoy the benefits of successful parallel development.

Have you seen the AccuRev 2-minute demo?

1 comment »

Posted in AccuRev, Best Practices, Customer Guest Blogs, SCM Resources

Tags:

Vim plugin for AccuRev – 1.0 Release

January 31st, 2008

I’m happy to announce the first gold release of the AccuRev SCM integration for Vim!

For those AccuRev users Vim plugin - File Editingout there that know the true power of the vim editor, life just got even better. Now you can perform over 30 commands directly within vim including keep [\k], promote [\p], update [\u], merge [\m], revert [\rb], diff [\db], status search [\s], and more! The plugin is per-buffer so you can work on multiple files concurrently and perform AccuRev actions on each file Vim plugin - Multiple=independently. In addition, you can work in either console or GUI (gvim) mode! Here are some additional screenshots of the plugin in action.

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

The plugin currently requires Vim 7.x and supports AccuRev 4.5.x and the latest 4.6.x. I developed and tested the plugin on both linux (Ubuntu 7.10) and Windows (XP) platforms.

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

No comments »

Posted in AccuRev, News, SCM Resources

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:

Understanding AccuRev Stream inheritance, the short version…

November 13th, 2007

In my role working with prospects evaluating AccuRev – and other SCM systems – the following question comes up often; “How are streams different from branches?” What’s the big deal? Usually the question is raised in the early stages of investigation, before gaining a real understanding and appreciation of the superior architectural differences that AccuRev brings to the table. There are other more comprehensive SCM resources out there which you can use for education, but I thought I’d present a brief, and quite real customer example.

Let’s say that you are using a branch-and-label version control tool, doing mostly mainline development (since branching is discouraged by a surprisingly large number of vendors out there!), and a major project comes up. Your Graphical User Interface has fallen behind the times and you want to update it to current standards. The boss assigns a developer or a team to this project and says, “Go to it, and I don’t want to see or hear from you for 6 months until it’s done.” So the team does what they have to do, creates a branch off the current mainline, and happily codes away on their “island” for 6 months.

Fast forward those 6 months. The project is reviewed, the GUI looks fantastic, and the go-ahead is given to roll it in; they want to release the hot new look-and-feel with the next major release. Oh by the way, the next major is scheduled for next month. Well, this is when that GUI team looks around at each other, scratches their heads and says, “How in the hexadecimal are we supposed to merge 6 months of changes back into the mainline?!?!” Not to mention getting them tested against what’s already been under development all this time.

AccuRev streams, and inheritance specifically, to the rescue!

Inheritance diagram

Mainline development is going on with the core development team working on their code, and promoting up toward release through an Integration environment, on to the QA folks, and finally approved for GA. Meanwhile, when the GUI project got underway they simply created a dynamic stream based off of the Integration area. The developer(s) now can work in a private project stream hierarchy and their changes, even when promoted to their parent stream, will *not* impact the mainline at all. That’s very nice, but the flip side is where it gets cool. Because of inheritance, any changes that the mainline team promotes to the Int stream or higher are automatically going to flow down to the GUI proj. This means that they will be able to maintain a constant integration with the latest and greatest, while still advancing their own project in isolation. When that 6 months is up and the green light is given, the only step left is to promote all the work from the GUI proj stream into the integration stream. Merging has already been done (and tested as well!)

For the longer version, please see the following Stream-Based Architecture for SCM white paper by Damon Poole.

Sound like a better approach? I think so. What kind of challenges are you currently facing in your own development regarding branch/merge scenarios?

No comments »

Posted in AccuRev, Best Practices, SCM Resources, Tips and Tricks

Tags: