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!
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?