The thing I have been noticing is that people with AccuRev perceive "branches" differently, more as a natural feature of a source tree. I sincerely believe that is a result of the visualization provided by the stream and versions browsers. They arm people with a clear cognitive model, whereas the old folder and file approach can only effectively visualize branches as folders, just like everything else. The result is that AccuRev users can both depict and describe a complex branching structure much more easily, and users of traditional systems generate crazy graphs which do more to obscure the branches than illuminate them.

I was having a discussion about AccuRev and branching today at the office. We are still transitioning some projects over to it, so there is some development using SourceSafe and some using AccuRev. The effort required to maintain even a minimal isolation with two branches is hugely largely than the same task in AccuRev. In the midst of this discussion a thread about complex branch management and traditional SCM systems was brought to my attention. Just look at the images on the Microsoft Branching and Merging Primer . The graphs themselves become steadily more difficult to understand as you move from simple branches down to code-promotion and component branching.Meanwhile, a project I am managing right now, in AccuRev, is actively using both code-promotion and component (sub-project branching). We have the classic Product_Rel->Product_QA->Product_Int streams which allow us to ensure development is stable before moving issues to QA. The QA department can verify the changes function before moving them to Rel. The release build is then an aggregation of all of the features which really work together.Additionally, we have three streams below Product_Int for sub-projects. First, is a stream for merges from a product developmed in VSS. We promote changes from it in cohesive groups, but only as time permits. If this stream gets out of sync with its parent, we take note of overlaps and resolve them in the merge source stream without destabilizing the Product_Int stream. This permitted us to merge little bits at a time over a period of four weeks. We also have a stream devoted to refactoring a specific subsystem. It too is able to take advantage of overlap notification to stay in sync with its parent. Finally, we have a time-locked stream which we use to service an internally released tool. This structure, though technically more complex than those depicted above, is far simpler for us to maintain and use; even for people who do not eat, sleep and breathe SCM. Why?After some thought this is what I wrote to the person who pointed out the primer:

Labels: AccuRev, DeLorme, SCM, technology, work