DVCS myths & factsUnless 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 curveReplace “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 securityToday 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 textDown 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 sourceTell 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.