DVCS buzz
Have you ever heard about DVCS?? I bet if you're a developer and you've being somehow living on planet earth at least once on the last twelve months you must have heard about Distributed Version Control Systems. Haven't you?Even the great Joel Spolsky dedicated his last ever post to DVCS.
What's all this buzz about?
Look, some cool guys on the software industry made their talk on what they feel version control:
So, it seems a nice trend has been created but... what is it all about?
Look a little bit careful at Spolky's link: what is he talking about? Being distributed is really powerful but at the end what they're all talking about is about branching and merging. Yes, as simple as it sounds, all the buzz on the hundreds of tutorials out there are focusing more on good-ol branching patterns than on distributed itself.
Why?
Because this new wave of DVCS evangelists (ok, it's cooler to put DVCS than branch on a headline) is singing a totally different song than the previous generation, exactly the opposite lyrics: instead of avoid branching at any cost they're now singing "let's embrace branching as a daily common practice".
Why?
Because you can.
Yes, as simple as that: the previous generation of SCMs were unable to handle hundreds and hundreds of branches and merges: it would be a suicide with CVS and VSS, it would be painful as hell with Subversion and other commercial systems wouldn't do better.
But now there's a brand new generation ranging from Git, Bazaar and Mercurial on the free side to Plastic SCM on the commercial one, which are not only distributed but let you branch and merge as you never seen before.
(Side note: here's our branch explorer showing the whole "forest" of branches and branches and branches)
It sounds to me really like the agile methods wave a few years ago: don't avoid change, simply embrace it. So, let's do the same here: don't avoid branching, simply embrace it... with the right tools!
Absolutely. A couple of years ago, we were split on a decision between Plastic and Perforce for our source control. Because of a small set of features (triggers among other things, which I believe Plastic now supports) not being supported in Plastic at that time, we ended up going with Perforce as our SCM, and now, we're stuck in a situation where we're having to carefully decide how to structure our repository in order to branch a project.
ReplyDeleteI knew I should have pushed harder at that time for Plastic, but I ended up capitulating, and now our situation is far from ideal.
Hi foxxtrot!
ReplyDeleteWell, we're currently migrating a good number of good-ol P4 users into Plastic... so you know where we're :-)
Yes, Plastic matured A LOT in the last two years: distributed is stronger, performance is simply 20 times better (which puts us in a very nice position), and then we count with things we were missing then like you mentioned...
We're working on very cool things right now like integrated code review and so on...
it's not just about branching and merging. it's about working in your own sandbox, not having to wait on someone, or a process; not being tied to a server.
ReplyDeleteAnd in case of open source, not even having to ask for permission or commit-access.
Absolutely! But branching and merging are key for having sandboxes.
ReplyDeleteFeature branches (or topic branches, or task branches or whatever you want to call them) are there to enable sandboxes.
http://www.cmcrossroads.com/bradapp/acme/branching/