Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

DVCS buzz

Tuesday, March 23, 2010 Pablo Santos 4 Comments

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:

  • Linus Torvalds himself advertised Git and DVCS to the limit (check it here).
  • Mark Shuttleworth (the former CEO at Ubuntu, just in case you're an alien ;-P ), talked about branching and merging (check my post here) and has a clear interest on Bazaar.
  • And I already mentioned Joel "the blogger" talking about DVCS.

    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.


    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".


    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!
    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.

    1. 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.

      I knew I should have pushed harder at that time for Plastic, but I ended up capitulating, and now our situation is far from ideal.

    2. Hi foxxtrot!

      Well, 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...

    3. 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.

      And in case of open source, not even having to ask for permission or commit-access.

    4. Absolutely! But branching and merging are key for having sandboxes.

      Feature branches (or topic branches, or task branches or whatever you want to call them) are there to enable sandboxes.