It’s Wednesday morning. 9:23am. With coffee in hand you execute a simple version control command: update.
Hey, blame yourself! You should have known better than to blindly accept all changes from every developer who quickly committed code the night before just minutes before darting out. What did you expect to happen? For teams that work on a single branch, broken updates can be quite common. For those that branch for isolation, their updates are comparably more stable but they are required to (painfully) merge more often to stay in sync.
Ok, lets get real. On some mornings, performing an update can yield minimal-hassle results and we all know that staying up-to-date is always a good thing. But often when you least expect it, often when it matters the most, often when time is critical, the simple execution of an update results in sheer and utter frustration. You know. The code doesn’t even compile. Forget passing unit tests. Forget working at runtime (these are the worst to deal with!). The last thing you want to do is spend the entire morning scrubbing logs, reverting out changes (complete WOT!), or walking the halls finding the culprit only to see that everyone you need is in a meeting in some cleverly named conference room.
But you had to! You know you need to update frequently in order to stay current with your peers. But back in your mind, you’re worried that their changes are going to negatively affect your changes. Nevertheless, all you can do is…. update. But what if you had control over the situation? In this pattern for stable development, I’ll describe an approach in AccuRev that provides incremental updates based on predefined good builds and minimizes merging (due to implicit merge tracking).
The Pattern. AccuRev’s stream-based architecture with built-in inheritance and time-safe snapshots can entirely eliminate the traditional problems of shared development (with branches). The first thing to acknowledge is that you need to work off of a stable codeline. period. 
I know, I know. Some of you reading this think you need to always be working against bleeding edge in order to move as quickly as possible. Fine. Then you accept the top-half of this blog post and are willing to deal with the pain/time/sleep/sanity lost in the ether. For the rest of us who don’t live at the office, we need to work off of a stable codeline. With AccuRev, this means working from a snapshot (or time-based stream). In a previous blog, I wrote about a pattern for continuous integration (CI) where snapshots are created for each frequent “good build.” Extending this CI pattern, lets use each good build snapshot as the baseline for active development. The idea is simple: Reparent your workspace or project stream to subsequent “good build” snapshots and then update. The update will bring down (delta!) changes to your workspace since the last good build. In this way, you knowingly accept changes that are guaranteed to have passed some level of test criteria. In the meanwhile, changes in the mainline Integration stream can churn-n-burn with various levels of volatility without affecting your active development environments — you’re saved by the snapshot! After days or weeks of hopping build snapshots, when it’s time to deliver your changes to the rest of the world, simply reparent to mainline Integration, perform any last minute merges, test, then promote! For an extra level of stability, consider only working off of certified builds – snapshots that have passed rigorous tests.
Wait. Who does the reparenting? Good question. I say let the developers or team leads manage where and when project streams get promoted. Reparenting is easy and reversible! On the other hand, maybe your CM or Release Engineer takes on responsibility for managing builds and reparenting projects on particular days or by request. You can use stream locks to easily control who can reparent, by user or group!
What about setting a time rule on a stream? As you know, snapshots represent configurations at specific points in time. You may also know that you can optionally set a time rule on a dynamic stream to control (i.e. throttle) when changes are inherited from the parent streams. 
[StreamBrowser: Rclick Stream --> Change Stream --> set time]. Guess what! The effect of reparenting to snapshots can equally be obtained by simply setting a time rule on your parent stream! This works best if you have a stream-per-task paradigm so the time rule only affects your (team’s) active development. The idea is simple – anytime you want more changes, simply (re)set the time forward say an hour or day or week and any newer changes will be available to downstream streams and workspaces. Personally, I like setting time rules only for temporary use cases such as for quick testing or to wait a day for new changes. If I’m doing development that will take weeks to complete, I’d rather reparent to a snapshot because it lets me physically ’see’ where I’m working. But both options result in the same effect — controlled updates.
This pattern is ideal for letting teams stay up-to-date by reparenting to stable baselines and only updating changes that are known to have passed some level of testing. Ultimately, with clean(er) updates, the results should be increased productivity, increased quality, and happier developers! Happy developers == good.
/happy coding/ – dave
You know, it is funny. I know about this paradigm. I suggested it to every one of the 125 developers who were working on my last project. But did I do it myself? Of course not. And I suffered. And those who didn’t listen to me suffered. Those who listened to me didn’t have a problem. *sigh*