Meta: On version-control techniques
I've been thinking alot about version control lately, because we're undertaking a big move from Clear Case and it's Unified Change Management (UCM) process to Subversion, which is the source-control equivalent of the Wild Wild West--anything goes, wheee!!
Meetings were held, proposals submitted, cost advantages debated, and finally the Big Muckety Muck cowboyed-up and made the call--we're going to subversion and saving a gagillion dollars.
As with many such decisions, this was communicated to the worldwide distributed sites with the utmost care, forethought, and consideration. That's right--it was 13th out of 15 slides in a Powerpoint deck. Aforementioned plebians reacted with anything from curiosity to outright rebellion.
...but, I digress....
So, I'm in the unique position of having experience in both systems--we rolled-out subversion in my old job and grew to love its power, flexibility, and simplicity. It worked, it was consistent, and it stayed the heck out of your way. If team 'A' wanted a completely different workflow from team 'B', Subversion didn't care--it was happily managing your code repository.
ClearCase (CC), at least in its UCM incarnation, doesn't work that way. Now 6 months in, I can appreciate where CC is coming from. This is a system designed not for self-managing teams, but for entire distributed organizations, founded on the assumption that propgrammers are idiots.
(Having read The Dilbert Principle, I'm coming around to this point of view. We're *all* idiots, and systems designed with that in mind have a good shot of succeeding in the marketplace. Democracy, MS Windows, and Automatic Transmissions all share that assumption. They're doing okay. )
Anyway, from a high-level, ClearCase UCM operates on the principle of Reverse integration: A Product is broken into modules, each module has its own line of development, and each team member has his own copy of that line of development. In ClearCase Terms, that line of development is known as the Integration Stream, and my clean copy is the development stream.
Clear as mud? It was to me, coming from a forward-integration subversion background. In forward integration, you check-in code to the main line of development. If you assume that programmers aren't idiots, then this makes perfect sense--put your code directly into the product, so the next time it builds your changes are there. Moreover, your changes are visible to everyone immediately upon check-in. That's forward integration in a nutshell. Simple. Effective.
And...prone to this: Billy checks-in code right before leaving for the day and breaks the build. The Whole Build. Everyone who's there until 2am can't do any more work until they fix the build error. They get mad at Billy. Emails fly; IMs twitter. Billy's team-lead Darold has to come in at 9pm to fix Billy's mistake.
The above scenario is very common to anyone who's run under continuous integration or forward integration. Indeed, my wife lived in fear of me calling at 5pm and saying, "The Build is broken." If you're a professional and living under forward integration, build failure means everyone stops work until it's fixed.
Reverse integration takes a different view. Everyone's imperfect--some folks screw-up with regularity--and you need to insulate the product from that with manual or automatic "gates" from changes getting into the product. So, you make people develop in branches, then they ask the system to integrate their change set into ONLY THEIR SUBMODULE, and if that works, the system moves it down the line, eventually integrating it into the product. (Lord willing, there's some automated tests somewhere in that line ::sigh:: I miss Java and Dependency Injection.)
Microsoft uses massive Reverse Integration; it was a cornerstone of Vista development (no jokes, please...). I think it's an intriguing concept that scales very well, and separates concerns about compositing the Product from those who develop the features.
So, I'm beginning to see what it is about Subversion that's making people nervous--it's not the semantics or the version control primitives--those are pretty much the same--it's the missing UCM process. Hmm...
Meetings were held, proposals submitted, cost advantages debated, and finally the Big Muckety Muck cowboyed-up and made the call--we're going to subversion and saving a gagillion dollars.
As with many such decisions, this was communicated to the worldwide distributed sites with the utmost care, forethought, and consideration. That's right--it was 13th out of 15 slides in a Powerpoint deck. Aforementioned plebians reacted with anything from curiosity to outright rebellion.
...but, I digress....
So, I'm in the unique position of having experience in both systems--we rolled-out subversion in my old job and grew to love its power, flexibility, and simplicity. It worked, it was consistent, and it stayed the heck out of your way. If team 'A' wanted a completely different workflow from team 'B', Subversion didn't care--it was happily managing your code repository.
ClearCase (CC), at least in its UCM incarnation, doesn't work that way. Now 6 months in, I can appreciate where CC is coming from. This is a system designed not for self-managing teams, but for entire distributed organizations, founded on the assumption that propgrammers are idiots.
(Having read The Dilbert Principle, I'm coming around to this point of view. We're *all* idiots, and systems designed with that in mind have a good shot of succeeding in the marketplace. Democracy, MS Windows, and Automatic Transmissions all share that assumption. They're doing okay. )
Anyway, from a high-level, ClearCase UCM operates on the principle of Reverse integration: A Product is broken into modules, each module has its own line of development, and each team member has his own copy of that line of development. In ClearCase Terms, that line of development is known as the Integration Stream, and my clean copy is the development stream.
Clear as mud? It was to me, coming from a forward-integration subversion background. In forward integration, you check-in code to the main line of development. If you assume that programmers aren't idiots, then this makes perfect sense--put your code directly into the product, so the next time it builds your changes are there. Moreover, your changes are visible to everyone immediately upon check-in. That's forward integration in a nutshell. Simple. Effective.
And...prone to this: Billy checks-in code right before leaving for the day and breaks the build. The Whole Build. Everyone who's there until 2am can't do any more work until they fix the build error. They get mad at Billy. Emails fly; IMs twitter. Billy's team-lead Darold has to come in at 9pm to fix Billy's mistake.
The above scenario is very common to anyone who's run under continuous integration or forward integration. Indeed, my wife lived in fear of me calling at 5pm and saying, "The Build is broken." If you're a professional and living under forward integration, build failure means everyone stops work until it's fixed.
Reverse integration takes a different view. Everyone's imperfect--some folks screw-up with regularity--and you need to insulate the product from that with manual or automatic "gates" from changes getting into the product. So, you make people develop in branches, then they ask the system to integrate their change set into ONLY THEIR SUBMODULE, and if that works, the system moves it down the line, eventually integrating it into the product. (Lord willing, there's some automated tests somewhere in that line ::sigh:: I miss Java and Dependency Injection.)
Microsoft uses massive Reverse Integration; it was a cornerstone of Vista development (no jokes, please...). I think it's an intriguing concept that scales very well, and separates concerns about compositing the Product from those who develop the features.
So, I'm beginning to see what it is about Subversion that's making people nervous--it's not the semantics or the version control primitives--those are pretty much the same--it's the missing UCM process. Hmm...
Comments
Post a Comment