DVCS myths & facts
Unless you’re not in the software industry or you’ve been down to Mars for the last 5 years, you’ve heard about DVCS. It stands for Distributed Version Control System and well, it is simply “the way to go in planet Earth for all programming related stuff”.
Admittedly I was more than happy today when I went to the SD Times front page and read: “Branching and merging: the road ahead for SCM”, which is cool considering “branching & merging” is the heart of our daily work.
This is our mantra!!
We always say “branching and merging is good”, we designed Plastic SCM from the ground up back in 2005 to help all the small and medium teams in companies out there moving towards parallel and later distributed development.
And now, certainly thanks to DVCS major players like Git and software heroes like Linus Torvalds, it became a major industry trend.
Version control used to be a commodity circa 2004, but 2005 rocked the SCM world and a new wave of tools tossed the foundations of the configuration management sector: big tools like PVCS and ClearCase and mass-oriented ones like Subversion started to vanish away.
And a brave new world emerged shaped to the form of the new development trends: agile, faster, more dynamic and fully distributed.
But, as usual, there’s confusion:
I’m trying to come up with a list in the purest Chuck Norris facts style about what’s true and what’s not true about DVCS. But, to start with, I’ll simply try to check whether 4 DVCS myths stated in the article in SDTimes are true.
Myth one - DVCS has a steep learning curve
Replace “dvcs” by “git” and you’ll get the original statement.Well, it is simply incorrect: there’s much more to DVCS than Git. Give a try to Hg, check Plastic SCM or simply read a little bit more about Git and you’ll find that learning DVCS is not harder than learning Subversion or Perforce.
Myth two- DVCS GUIs aren’t there yet
“There is no effective GUI yet, so it appeals more to power users than enterprise developers.” (sic Perforce’s Randy DeFauw)As a Plastic SCM developer this is fun to read. I know he is talking about Git, but still :P Our system is all about cool GUI and advanced DVCS. Compare Plastic SCM with others and check our GUI effectiveness.
Myth three- DVCS requires a full replica on each developer machine, compromising security
Today I feel like we were doing our homework down here at Codice: while this can be true for Git or Hg, the good thing with Plastic SCM is that it is all about choices: you want it centralized, fine, you want it distributed, fine too, you want a full replica, right, you just need to replicate a single commit (changeset) to your laptop, work on it and push back to the main server later on… fine!Regarding security: ACL based sec, triggers, up to 7 standard database backends, LDAP support built-in… what do you mean by “compromised”?
Myth four - DVCS can’t deal with big files and it is only designed for text
Down here we test Plastic SCM 4.0 with a checkin of 1Tb in a single file.You read correct: 1 TeraByte inside a single file.
And yes, we run circles around Subversion while doing it.
SO: maybe Git or Hg have big trouble dealing with big files, but Plastic SCM is distributed and can deal with files as big as you can handle, that’s why, for instance, some reputed game developers already use Plastic SCM.
Myth five - There is no “master” file or canonical source
Tell that to Mr. Torvalds and his “dictator/lieutenant” controlled integration model.No master file? Being distributed doesn’t mean there’s no canonical source. You can have more than one repository but still kwon which one is the master copy.
Unable to do a replica doesn’t mean you’re better organized (SVN, Perforce), it only means you’re unable to do distributed work.
'The way to go on planet Earth'... Isn't this a bit dangerous (totalitarian--no offense intended: looking for a technical word-- unique thought, etc...)?
ReplyDeleteAnother danger is that totalitarism (in thinking) is now new, and that 'labels' (or 'tags') like this one, may have little discriminating meaning with respect to the ones used 6 months ago (remember Oscar Wilde: fashion is such an ugly thing that you have to change it every 6 months).
So 'DVCS' is in great danger to mean just the same as 'Continuous Integration', or as 'Patterns' (to name just a few), i.e. nearly nothing...
Another thing is that branching and merging have no as much to do with each other as was thought 30 years ago. It is just one of the most expensive misconceptions of XXth century that one has to merge *back* eventually, and that even this 'merge back' *is* (properly) a merge. It is very seldom.
Hey Marc, great to hear from you down here!
ReplyDeleteWell, I believe DVCS is a great revolution for many teams out there. Probably not for you, a hard-core ClearCase expert, but most of the teams in the development universe are still tied to SVN-way-of-thinking methods.
Git, Mercurial, and Plastic SCM are helping many teams to unlock the "mainline" approach they're tied to.
That's all.
But, if you ask me: yes, DVCS can end up being a buzzword, especially since the ones that ARE NOT distributed (such as Perforce, SVN, TFS and many others) try to get people confused (for economical reasons) and make them think "an open tcp port and a proxy" is the same thing. It is obviously not!
Hi Pablo,
ReplyDeleteI keep an eye here from times to times...
I have had recently issues with Git afficionados who:
- would not recognize anything distributed in ClearCase
- are ready to praise Git whatever happens.
I see two main patterns of use of Git in practice:
- the Linux kernel, where the repo is locked and guarded by committers, in the most old-fashion and traditional way
- Gerrit/Github based uses here and there, where integration takes place in a centralized repo.
Correct, the DVCS aspect of Git is that you have a full repo instead of a mere snapshot, and you can use it to collaborate with a small team.
But a real distributed breakthrough?
None.
I keep thinking on the contrary that the focus on sources is deadly wrong. Far too expensive. One should get the build before the sources! And make the decision to run tests based on increments in the build dependency structure instead of in the source code. Communicate recorded uses, instead of opinions of trusted friends.
In this sense, the dvcs revolution seems to me to be backwards by 20 years in some essential aspects!
Then, there is my pet pieve concerning branching off and not merging back. Another time.
Hi Marc,
ReplyDeleteWell, the breakthrough is the following: ClearCase was a impressive system, probably one of the bests ever built. That being said, more often than not I see teams dropping CC and moving to ... Subversion!!! I couldn't understand it!!
But there's a reason: they were using ClearCase UCM. UCM is like taking a Ferrari, removing the wheels and then asking why people goes faster on a Fiat... yes... without wheels a Ferrari is pointless.
Besides, like a Ferrari, ClearCase needs lots of maintenance. I only know a couple of good CC administrators... and if you don't have CC properly set up... it sucks.
Now, after a "dark age" that lasted for 5-9 years with SVN as dictator... Git, Mercurial (and Plastic SCM too) bring fresh air... Was it invented before? Yes, like The Renaissance was about revamping the classics... the DVCS age is about getting old forgotten good practices.
With Git and Hg you can do things that were simply not doable with SVN.
And, yes, CC had Multi-site... which was a hard to set up beast costing $8k per user... The new DVCSs are able to replicate out of the box... so yes, the same good-old ideas but finally correctly implemented...
We're on some projects running merges involving 200k files... CC used to do it in 18 hours... we do it in under 1... Well, some things changed! :)