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.

The version control timeline

Monday, November 15, 2010 Pablo Santos 112 Comments

Edit Jan 10th 2018: Brad Appleton (of SCM fame), contributed a comment adding more info about Aide de Camp, about the first version controls available for PC(DOS) and highlighting that task branches are not the same as feature branches, something we try to stress on all our communication but failed to do here :-)

It is also worth to note that we have a specific site for version control history.

Edit Feb 12th 2014:We just collected all the comments and suggestions from readers and created a dedicated site with a bigger number of version controls here. Enjoy :P




Software Configuration Management (or source code management, for you real hard core coders) has been around for quite a few years, slowly moving from an almost manual-labor, dark prehistory to the shiny days of the DVCS (distributed version control system).

You've all used at least one of the SCMs on the following list, but are you aware of how long the system you're using has been around? Do you know the big names? Ok, that's what I'll try to supply with this short compilation.

The big picture

Look at the following diagram to find some of the main names in SCM history. Yes, I must be missing a good number of them, so don't be shy: post a comment and I'll update the list with your favorite one I missed :)

If you're still feeling good about using really "old irons", I've added some pictures of how "cell phones" looked like when the SCMs were released, so you feel older and bloody outdated :). So yes, if you're using CVS and still think it's ok, look at the cell phone directly below "CVS" in the diagram. Do you feel like Gordon Gecko (Michael Douglas) in "Wall Street, Money Never Sleeps", getting his brick-sized cell phone back as he leaves jail?

Prehistory

There was a time when you stored your versions manually. Ok, for many of you this time wasn't the 80s, but a few years back when you were at college naming your source-code archives exercise.zip, exercise-0.zip, exercise-good.zip, exercise-good-final.zip, and so on. Well, believe it or not, there was a time without real SCMs. It was always dark and people were living in caves.

RCS

Then 1982 came and RCS was released. RCS is not a huge piece of technology, but you can still find it around in Unix distros. It is simple and straight to the point.

One nice feature was that text changes were stored as deltas (pretty important, considering hard drives used to be small!). Deltas are still used nowadays by most SCMs.

Some RCS drawbacks worth mentioning:

  • It is text only.
  • There is no central repository; each version-controlled file has its own repo, in the form of an RCS file, stored near the file itself. For example, the RCS file for /usr/project/foo.c is /usr/project/foo.c,v -- or a little better, in a subdirectory, /usr/project/RCS/foo.c,v.
  • Developers make private workspaces by creating symbolic links to RCS subdirectories – say, a symlink from /usr/home/john/RCS to /usr/project/RCS.
  • Naming of versions and branches is downright hostile. A version might be named 1.3, and a branch might be named 1.3.1, and a version on the branch might be named 1.3.1.7.

The classic era

In the SCM arena, the 90s are the classic era.

CVS

It all started with CVS (Concurrent Version System) in 1990. It was able to handle multiple versions being developed concurrently on different machines and stored on a central server. The client-server age was upon us and developers took major advantage out of it.

CVS was able to handle versions in a decent way. And it even supported branching and merging, though it wasn't very good at doing it. That's one of the reasons many people are scared about the "B" word and the "M" word.

CVS didn't track directories or filename changes (no refactoring allowed here!) and heavily relied on locking the whole repository. It is outdated now, but it worked in the 90s! (If you have it, just walk away and go on to something else!)

PVCS

Polytron Version Control System (PVCS) was initially released in 1985 and then went through a series of mergers and acquisitions: Polytron, then Sage, Merant, and finally Serena.

It's an old, outdated system (initially designed to avoid branching/merging, using file-locking instead), but it's still supported by Serena Software.

ClearCase

In 1992, one of the major beasts in the SCM world was born. ClearCase was clearly ahead of its time and for some it is still the most powerful SCM ever built.

Outdated, slow moving, over priced, and overly complicated to administer (in the early days, you had to generate a new Unix kernel to run the beast!), good-old CC isn't the cool guy anymore -- you can hardly find anything positive about it on the net. But it's still very good at branching and merging and still has unique features, such as its legendary "dynamic views". While powerful, CC came from a time when disk space was scarce and networks were mostly LANs, with no concerns for things like latency or working through firewalls.

Atria (the developer of ClearCase) merged with Pure (which was run by Reed Hastings, now the head of Netflix), was purchased by Rational and then IBM. And lo, the powerful CC stopped evolving. Well, it did evolve towards UCM in the early 2000s, which basically got rid of all the good things and left the weak ones, together with a huge price. Not very good idea.

ClearCase is still one of the most-used SCMs in the corporate world, and certainly one of the revenue leaders.

VSS

All the systems on my list had their moment and their clear advantages over previous systems. All except Visual SourceSafe. VSS was a weak system from day one, forcing developers to work with a "locking" approach, discouraging parallel development and creating a huge "fear of merging".

Slow, error prone, and utterly limited, VSS has been one of the most-used systems by Windows developers around the world. It is still in use, spreading pain and fear among good-hearted coders. But VSS was ahead of its time in one sense: it more properly belongs in the "dark SCM middle ages" (see below), instead of the classic era.

VSS was entirely graphical, which was probably one of the reasons why it was widely adopted (along with being closely tied in with Visual Studio distributions).

Perforce

Perforce (P4) is one of the independent vendors who are totally focused on SCM, battling for the SCM gold. It is still one of the market leaders among mid-range companies with huge teams, and it has a strong presence in some market niches, such as the gaming industry.

When it was released in the mid 90s, P4 was one of the most affordable and powerful systems to date. Worlds ahead of VSS and CVS, it was never at the level of Clearcase. But it was able to clearly beat CC in cost, performance, and ease of use.

Being centralized and not very good with branching and merging (branches are implemented as subdirectory trees – didn't they ever hear of metadata?) P4 doesn't seem to be the best option for the future, but it is rock solid, mature, and well established. That will help it keep growing. At the time of this writing, P4 is the biggest code repository inside Google. Cool!

Enter the middle ages

A time of darkness, when most of the previous advances were lost and a degraded environment emerged...

Subversion

Subversion (SVN) was conceived as "enhanced CVS" and its developers hit their target: it is better than CVS. Period.

Although systems like ClearCase were perfectly capable of branching and merging, SVN educated an entire developer generation on the following dogma: fear branching and merging at all cost! This caused environmental damage that persists to this day, only starting to be healed by the new DVCS generation.

SVN was close to P4 in features, and spread like crazy: more than 5 million developers around the world use SVN on a daily basis. Huge!

SVN is extremely simple to use and evangelized everyone on the "mainline development model". Error-prone (break the build!) on non-toy projects, it helped developed techniques like "continuous integration" as a way to "avoid integrations". While the idea is good, most of the surrounding concepts were clearly limited by the tool itself.

Linus himself raged against SVN when he first introduced Git back in 2006.

During 2009 and 2010, all major open-source projects on earth gravitated away from SVN. A good sign of how wrong SVN was. But it's still big and won't die for ages.

AccuRev

Born in an age of darkness, AccuRev was developed as an entirely new approach to source control. Its original way of doing things still seems new to lots of developers nowadays.

AccuRev has strong support for branching ("streams" in its jargon) and merging. It has played a valuable role in helping the community move away from ClearCase and older tools like CVS.

Enter The Renaissance

After an age of darkness, an entirely new generation of SCM systems broke the established status quo. "SCM is a mature market" was the analysts' conventional wisdom, but the new generation broke onto the scene and blew everything apart.

Able to sever ties with the Internet and work unplugged (like cool rock stars), the new generation also excels at branching and merging, which was touted as the root of all evil during the "dark ages". These new systems have successfully shifted the tide in the "branching/merging is good" direction.

BitKeeper

BitKeeper was one of the innovators in the DVCS field. Designed by Larry McVoy (who previously worked on TeamWare, Sun's internal version control system, built on top of SCCS, long evolution story here…) it rose to fame in 2002 when the Linux kernel development team started using it. A huge flame war started, with some developers complaining about using commercial tools for the world's premier open-source project.

Things only got worse in 2005 when fights with the core kernel developers grew even bigger. BitMover, the company behind the product, became concerned about people reverse-engineering their code. They discontinued support for open-source development and, ironically, thus prompted the creation of Git to fill the gap.

For more, see http://en.wikipedia.org/wiki/Bitkeeper.

Git

Linus Torvalds, the father of Linux himself, designed and implemented the first version of Git (almost over a weekend, in pure-hacker style) to give his kernel developers an alternative to BitKeeper. Linus not only did the original design (simple, clean, genius), but helped promote the project with his unique style. (See http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html.)

During his famous speech, he heavily criticized (ok, insulted) CVS, SVN, and Perforce: "Subversion has been the most pointless project ever started", "If you like using CVS, you should be in some kind of mental institution or somewhere else" and finally "Get rid of Perforce, it is sad, but it is so, so true".

You can love him or hate him, but he definitely made his point: the Middle Ages were over and now distributed systems were to rule the world, including removing the arcane fear of branching and merging, a key concept behind every DVCS.

During the next years, every major open-source project migrated away from Subversion towards Git (and www.github.com provided a really huge, huge hosting service), making it the strongest and coolest SCM on earth.

Git is based on a DAG structure (Directed Acyclic Graph), in which the main unit of change is the changeset. It implements full merge-tracking, but at the commit level instead of the individual file revision level (as, for instance, ClearCase does). It is extremely fast, with the only caveats being management of large binary files and the requirement to replicate repositories in their entirety.

Git is clearly influenced by its kernel roots, and it's obviously not the easiest thing on earth to use . But it will definitely be the SCM of the next decade. Check out this awesome book.

Mercurial

Mercurial (Hg) was first announced on April 2005, also rushing in after the BitMover decision to remove support for the free version. Hg is also one of the key open-source DVCSs, along with Git. They can even work together quite well: Scott Chacon, the Git evangelist and one of the best SCM tech writers ever, wrote a nice integration -- see http://mercurial.selenic.com/wiki/HgGit.

But Hg differs quite a bit from Git in terms of design. They share the concept of commit/changeset as the unit of change. Git implements this based on trees; each tree points to an older tree, and so on – hence the DAG. With Hg, every changeset is a flat list of files and directories, called a revlog.

(For more on Hg, including internals, see http://mercurial.selenic.com/wiki/Design and http://mercurial.selenic.com/wiki/DeveloperInfo.)

Mercurial provides very strong merging, but it's a bit different from other SCMs in its branching model: it has "named branches" but the preference is to create a new repository as a separate branch instead of hosting "many heads" inside a single one.

Joel Spolsky has written an extremely good Hg tutorial (hginit.com), which will help a lot of new users. Spolsky's company, Fog Creek Software, has recently released Kiln, a commercial wrapper around the Hg core.

Darcs

Darcs (Darcs Advanced Revision Control System) is another open source attempt to get rid of CVS and Subversion. It started in 2002 and has been continuously evolving since then, reaching version 2.5 in November 2010.

The major shortcomings of Darcs have been performance and its different way of handling history: instead of managing "snapshots" (commits or changesets) it manages patches, but in a way that makes traversing history difficult to understand. (a current status may have not been a real snapshot).

Bazaar

Bazaar (bzr) is another open-source DVCS, which tries to provide some fresh air to the SCM world. While less used than Git and Mercurial, Bazaar features interesting features, such as the ability to work in a centralized way, if needed. (The "pure" DVCSs didn't include central servers in their original design.)

Bazaar was developed by Canonical (yes, the Ubuntu company!) and became GNU in early 2008.

Plastic SCM

Plastic is a DVCS system designed with commercial use in mind instead of open-source projects (unlike Git and Mercurial). Plastic was first released in late 2006, featuring strong branching and merging, including full merge tracking and rename support in merges. It provides a highly visual GUIs, with many data-visualization capabilities, specially its unique Branch Explorer). This distinguishes it from DVCSs that are oriented toward the hard-core, CLI-oriented hacker community.

The motivation of Plastic's developers (BTW, I'm one of them) is to target small and medium teams, closing the gap between expensive high-end systems like ClearCase and low-end ones like SVN.

Plastic is built around the concept of parallel development, encouraging use of the "branch per task" pattern (do not confuse with long-living feature branches). It can handle thousands of branches without breaking a sweat. Plastic is also distributed, supporting disconnected development, pushing and pulling of changesets on branches, and conflict resolution.

Team Foundation Server

Microsoft, wanting to play a role in the SCM/ALM market, came up with Team Foundation Server (TFS). It's an effort to heal the pain caused by its own VSS devil.

While TFS is not very strong as a source-control system (kind of a new guy on the block, but using previous-generation technology), it comes fully packaged with a huge set of tools, from issue tracking to test management, in the pure "corporate-huge-integrated-thing-style".

You won't be doing branching, merging, or DVCS if you go for it, but maybe your company already purchased it, along with an MSDN subscription.

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.

112 comments:

  1. You are missing 'GNU Arch' (also known as Tom Lord's Arch, or 'tla' sometimes) (http://www.gnu.org/software/gnu-arch/) which was then forked to "Baz" (http://en.wikipedia.org/wiki/Bazaar_(software)#Baz:_an_earlier_Canonical_version_control_system) before Bazaar-ng (bazaar as we know it) was released

    ReplyDelete
  2. VSS didn't force locking. You could do multiple checkouts with it. See http://support.microsoft.com/kb/138475 - the primary benefit of VSS was it didn't require any server/daemon installation.

    ReplyDelete
  3. You are missing SCCS, even older than RCS.

    ReplyDelete
  4. I actually used SCCS at my last job. Unbelievable that some companies still use it. Useful chart and I love the comparison to cell phones.

    ReplyDelete
  5. Ed, look in the Bitkeeper section -- there's a mention of SCCS there!

    I used SCCS, also, but not at my last job -- in the mid 1908s. Actually, the release engineer built a very sophisticated "configuration management solution", built on top of SCCS and an old email system (MH, I think).

    ReplyDelete
  6. You are missing Aegis which was first released in 1991 with TDD and (mandatory) code reviews. Aegis got elegant branching in 1998. Aegis became a DVCS in 2002.

    ReplyDelete
  7. Hi all,

    Thanks for the commments!

    I'll update the graphic and text and will add the missing ones.

    I tried to select the ones I considered more important (or I liked more, or hated more!) so a nice bunch wasn't included (I also wanted to keep the graphic simple...)

    Anyway, I'll try to make it more and more complete...

    Thanks!

    pablo

    ReplyDelete
  8. RCS is not text only; you can maintain binary files in RCS. You just have to use "-kb" to keep it from accidentally expanding keywords when you check things out.

    It's also worth mentioning that CVS uses the RCS file format; CVS has the same binary-vs-text considerations RCS has.

    SCCS goes back to 1972, and was later ported to Unix. CSSC ("Compatibly Stupid Source Control") is GNU's clone of SCCS; it's still maintained, but not recommended for general use. The CSSC documentation says "GNU CSSC was originally based on the public-domain package MySC,
    which was written by Ross Ridge."

    VMS^H^H^H OpenVMS has a version control system called CMS (Code Management System).

    ReplyDelete
  9. Hi!

    I think you forgot monotone mentioned by Linus before starting GIT.

    http://lkml.org/lkml/2005/4/6/121

    Also, even MS was pretty aware of VSS not being for big teams. Their own docs recommended local small teams.

    ReplyDelete
  10. You also left out Digital Equipment Corporation's CMS (Code Management System) from the late 1970's, probably still used on some VMS systems.

    ReplyDelete
  11. Another shout out to SCCS. Originally developed in 1972, so a decade before RCS.

    ReplyDelete
  12. Thanks for this post. Overviews are quite nice to have. See also Current Concepts in Version Control System , by Petr Baudis for a more in depth and perhaps accurate view.

    We do not currently recommend Darcs for large projects, or for projects that need explicit history tracking. Darcs' perfomance is improving, but still has a way to go. The lack of explicit history can indeed make code archeology harder.

    So what are Darcs' strengths from our point of view? Well, its "different way of handling history" as you say. It's a double-edged sword. While we lose explicit history tracking, we gain ease and flexibility which we think are hard to reproduce elsewhere: (A) easy user interface and mental model - your repository is just a set of patches, (B) cherry picking everywhere - in Darcs it's easy to pick out exactly the patches you want to pull, undo, email, etc without worrying about their dependencies (C) semantic patches - darcs tracks high-level changes like "rename file foo.c to bar.c" or "replace token fizzle with fozzle in foo.c". In the future, we hope to have patches that, e.g., let us think of XML files as trees. We work on Darcs because these ideas are important to the future of DVCS; we hope that other systems will steal them from us!

    ReplyDelete
  13. We first had VSS and then TFS at work.
    Both are directly from hell and luckily I convinced them to switch to Git. We've been in heaven ever since :-)

    ReplyDelete
  14. Another missed system: Microsoft Delta. As I remember, it was the internal software used by Microsoft, MS saw an opportunity to cash in on the niche and productized it. It got replaced by VSS when MS acquired OneTreeSoftware.

    ReplyDelete
  15. As bad as VSS was, it did not originate with Microsoft. I remember evaluating tools about 1992 or so, and One Tree's Source Safe was one that did not even make the first cut. We settled on MKS's implementation of RCS.

    ReplyDelete
  16. I tried Git and Mercurial and found Git not very user friendly, and Mercurial hugely easy to use.

    TortoiseHG integration on Windows is slick, and the command line hg is easier to use, and things which should be one line, are one line, without any pipe (|) characters.

    Git is great if you're a total Linus-style gearhead. If the python-style of Mercurial is more your thing, I fail to see how that makes Hg "less well designed".

    Warren

    ReplyDelete
  17. apart from gnu arch (which looked like it was designed by a madman), you also missed monotone.

    ReplyDelete
  18. thank you for the overview, pablo.

    what's the best (tm) system to use if you have a lot of binary files? how does plastic scm handle these? who's best at binary deltas?

    .~.

    ReplyDelete
  19. TFS does indeed have branching and merging built into it. http://visualstudiomagazine.com/articles/2010/09/18/branch-by-release-in-tfs-2010-part-2.aspx

    ReplyDelete
  20. SCCS I remember using a lot, but because of using forward deltas, it took ever longer to check out a current copy. Along came RCS with its reverse-deltas, and I thought it was the bee's knees; however, we were still locked from concurrent version control. Et voilà! CVS! Nice, fun, still used, but I have moved on through SVN to darcs to git, and currently love git for what I do.

    ReplyDelete
  21. TFS handles branching and merging quite well actually, not sure why you made that comment. TFS 2010 is great. Shared checkouts, merging, branching, shelving changes temporary, etc..

    ReplyDelete
  22. @dot tilde dot

    Well, we do split big binary files in chunks (4Mb max), so I'd say we're not hit by size.

    Just to give you an idea, we just finished imported today a big repo of 300Gb from a gaming company... I can tell you they DO have lots of big files.

    ReplyDelete
  23. Sorry but I don't feel bad about still using RCS because it meets my simple needs: as a one-person developer and writer, I don't have any use for more complexity.

    It's hardly comparable to using a clunky old cell phone. RCS is slim and fast and functional, even if it's very old.

    ReplyDelete
  24. @mastro look, TFS uses "path space branching" which means branches are some sort of "special directories" like they're in SVN.

    What does it mean? It does mean that branching in TFS (like SVN) simply sucks. It's a huge pile of crap. How good are they dealing with files that have been modified on a branch and moved on another branch? Does TFS support free merging (or only children to parent)? Can you implement branch per task with TFS?? No, because if you try to have 4000 branches on it (I've more than that on my laptop running plastic on top of sqlite) you'll kill it.

    Besides, TFS is horribly slow...

    And they do all this stuff with only 10 times more developers than what we've... :DDD

    Of course, we're like babies compared to them in terms of marketing.

    Sorry to be so tough but, you know, I've to pick a side! :P

    ReplyDelete
  25. I don't feel the least bit bad about continuing to use RCS, which serves my needs as a single-person developer and author quite well. The cell-phone comparison is specious at best. RCS is slim and fast and functional enough. Old cell phones are not a valid analogue.

    ReplyDelete
  26. While I understand your point that many people are using outdated software, this post comes across as saying "anything that was around twenty years ago shouldn't be used anymore" at points, when everyone knows that's not always true

    ReplyDelete
  27. Continuus/CM (which is now also taken over by IBM). It probably combines all the bad features of all other commercial SCM, while being glacially slow, horribly expensive, a prime example of terminally inconsistent interfacing (I support this SCM from hell already 10 years).
    However, do you know of any other SCM system that is able to store source trees of over 4Gb? The number of developers is about 50.

    ReplyDelete
  28. Fossil should probably be mentioned somewhere. It is by the same guy that did sqlite (and uses sqlite to store its repository).

    What is interesting about Fossil, compared to the other DVCS systems, is that it also has a distributed wiki, bug tracker, and blog system. With the others when you set up a project you have to go outside the system to find some place to store your project wiki and bug tracker.

    ReplyDelete
  29. @Bungerting Baloner. Guys, don't take it too serious. I tried to come up with a funny timeline, it's not a thesis, of course.

    I think using RCS is fine if you use it for yourself. Isn't it.

    That's all.

    But what I find shocking is the following: teams using CVS and taking a whole year to decide to go to another system... I mean, it doesn't matter whether it is Git, Hg, Plastic, Perforce or Accurev, if you're using CVS... change!

    ReplyDelete
  30. @InSearchOfKnowledge "However, do you know of any other SCM system that is able to store source trees of over 4Gb? The number of developers is about 50."

    Yes, I do.

    Drop me an email to psantosl at codicesoftware.com.

    We've just imported a 300Gb today with a 30Gb working copy.

    ReplyDelete
  31. @tzs: yes, I should have added Fossil to the picture.

    The nice thing is that we also have the option to use sqlite as backend (is the one I do use on a daily basis)

    ReplyDelete
  32. @Anonymous
    "While I understand your point that many people are using outdated software, this post comes across as saying "anything that was around twenty years ago shouldn't be used anymore" at points, when everyone knows that's not always true"

    Sure, there's software there running for years, continuously evolving and getting better and better. Samples: Linux, Windows, gcc, Visual Studio... and many more.

    BUT: CVS, SVN, ClearCase and many others are dead beasts that are not evolving at all. That's my point.

    ReplyDelete
  33. When people say that Perforce is bad at branching... they have clearly never used Perforce. I'm seriously considering a Perforce -> Git migration but hesitant because Git is missing inter-file branching and merging making it useless for maintaining third-party vendor branches. Branching is where Perforce shines IMO.

    ReplyDelete
  34. In what ways was Perforce "never at the level of ClearCase"? ClearCase doesn't even have atomic commits (if you want to commit several files, and ClearCase errors out somewhere in the middle, it'll still commit the files before the error).

    Also, SVN has had merge history tracking since 1.5 (released in 2008). I still wouldn't use SVN, and I don't know how much better the merging is in 1.5, but it's not megahorrible anymore.

    ReplyDelete
  35. @Kannan try this http://codicesoftware.blogspot.com/2010/08/rename-support-on-merge.html with SVN and cry...

    Regarding P4: P4 is not as good as CC in branching and merging, that's all. They still use "path space branching", same thing as SVN, and it sucks.

    Every major OSS project migrated away from SVN during the last 12 months and the reason is merging and branching.

    ReplyDelete
  36. StarTeam... the bane of my existence...

    ReplyDelete
  37. @Anonymous: re: perforce
    I have been around scm for more than 15 years. Perforce is a decent tool and it's lightening fast. No question. But when it comes to branching and merging, it was not designed to handle deep parallel development. It handles merging better than SVN, and VSS and CVS. Considering P4 had the ability to merge since it's inception, there's no reason to doubt it can't handle it, and SVN wasn't able to handle merge tracking history until a little over 2+ years ago. That may be easier to argue since it wasn't part of the core stack, but I digress. But does P4 honestly handle nested branches that expand horizontally (maybe as deep as 4 or 5 levels)? We have several ex-p4 clients that chose Plastic over the aforementioned because it couldn't handle that level of branching. If you don't need that level of branching, P4 may be meeting your needs. Someone earlier commented that the argument is more around branching patterns and models, and that is more accurate. Will it handle branching and merging...absolutely. But if you're doing development that requires more sophisticated branching patterns, such as task-based development, no, P4 doesn't support that model.

    ReplyDelete
  38. Also, DSEE on Apollo workstations was the predecessor to ClearCase. DSEE is Domain Software Engineering Environment. One of the big deals was the build system and the concept of using dynamic and bound configuration threads as part of the system.

    ReplyDelete
  39. You should add Continuus (Telelogic CM Synergy) to the list too; back in 1998-2000, it did some things that I still feel are lacking from many VCSs today; task folders were an awesome concept, it actually versioned directory objects instead of a tree of files, so you could merge directories, it had great scriptable metadata queriability. It's somewhat of a competitor to Clearcase. Of course, it was slow and bloated and practically impossible to use across a WAN.

    ReplyDelete
  40. @All

    SVN is actually quite good. It uses changesets as it basic unit of version. Branching and Merging are quite good - even back in 1.2, and the feature to enhance it in 1.5 and 1.6 are superb. It's also quite actively developed.

    That's not to say that Git, et al may not do a better job. Just saying, SVN doesn't suck.

    That said, the main point of contention is that the developers sometimes refuse to listen to the community - e.g. see discussions per Tags.

    And all that said, if you were not going to use a DVCS then Subversion is the best you can get. Otherwise, it's probably Git.

    ReplyDelete
  41. Synergy is missing. I wonder how synergy compare vs clearcase. Is one product superior to the other. Which one is dying in favor of the other one ?

    ReplyDelete
  42. You are missing StarTeam.

    Version 4.2, which I worked with at GE in 2001-2003, already version control on files and folders.

    It also had a Change Request system, a Task management system and Topics (threaded, NNTP-like discussions), for widely distributed development teams. All of these things could be linked together.

    Someone could put in a Change Request (bug, new feature, whatever), it could be linked to a Topic about what to do, how to implement, etc., further linked to Tasks, which could be assigned to developers (and could be used to track hours spent developing, testing, etc.) and, finally, linked to particular revisions of files.

    It came in very handy, later on, when you wanted to know why a particular change was made to a file. Everything you needed (the bug, the discussion, who was responsible for doing what, how much work it took) was right there.

    It also had Views, which were subsets of the main repository. The fewer objects you had access to, the faster it updated.

    I administered it and generated some pretty interesting reports from it. It had a Java API for querying and changing the repositories.

    Version 4.2 was pretty balky and chewed up a lot of bandwidth. Also, the client only ran on Windows.

    Version 5.1 made better use of caching and was much more performant. It also had a credible web interface and a Java client. I was principally responsible for converting our division from 4.2 to 5.1.

    StarBase, which made StarTeam, was acquired by Borland.

    ReplyDelete
  43. You also left off Rational Team Concert, which I believe came into existence around 2007. It's an incredible, fast SCM, with great branching and merging, as well as distributed capabilities in the upcoming release. This is all pretty amazing considering that it comes from the same people that sell ClearCase, quite possibly the worst SCM tool ever made!

    ReplyDelete
  44. Well, I don't agree ClearCase is the worst SCM. Not at all. I think it is a pretty good one, but you've to spend some time learning it.

    ReplyDelete
  45. @pablo: CC branches files. Ouch. Nuff said. Good luck!

    ReplyDelete
  46. I used to support PVCS (Intersolv... you forget them) in another life. Ah, memories. Also it did branching and merging, though you will notice the lack of the word "well".

    ReplyDelete
  47. OK, replace "quite possibly the worst SCM tool ever made" with "quite possibly the most painful SCM tool ever made." (Which I would then equate with "worst," but, hey, to each his own...)

    ReplyDelete
  48. Uh yeah, not sure what kind of crack you're smoking, but TFS not only does branching and merging, but it does them better than any other source control system I've ever used (RCS,GIT,VSS,CVS,Perforce Dimensions).

    ReplyDelete
  49. second the rational team concert comment. good stuff, especially coming from IBM. We're an IBM shop, so it's good to see everything tie in together.

    ReplyDelete
  50. In the 80's there was Apollo Computers DSEE. Even though it was not organized around change sets like RCS you could label file revisions with a named revision. It was integrated into the OS and filesystem. There was an environment variable you could set to a revision name and then the files would "be" at that revision. It died after HP bought Apollo.

    ReplyDelete
  51. TFS better than Git??? Ouch!

    Why don't you give Plastic SCM a try and compare?

    ReplyDelete
  52. Look, there was SCM long before RCS. At my first job, we had a Source Control department. When you had your code ready to go, you took your floppy disks to the nice ladies in Source Control, they would take your disks, duly update the library, and build the customer-ready product from the officially reposed source.

    On a later product, we modernized and developers started maintaining the source code repository themselves using SCCS.

    ReplyDelete
  53. @Miles Duke

    "you took your floppy disks to the nice ladies in Source Control"

    Nice ladies doing Source Control is better than plastic scm.

    Agreed!

    :)

    ReplyDelete
  54. Perforce's branching may be directory based rather than in-situ and transparent, but its a real branching solution. Yet you have it to the left of a "fear of branching" moment.

    The real high-bar for merging across branches is "merge through rename". Refer http://www.lucasward.net/2010/02/maturity-model-for-source-control-scmm.html

    ReplyDelete
  55. Speaking of prehistory, Control Data had a system called Update that was a primitive version control used mainly for the os sources back in the early '70s. and maybe before that, not sure exactly when it was first used.

    ReplyDelete
  56. If you really want to to truly ancient history, you have to go back to delta decks on punch cards.

    That was 780's for me, I don't remember the name.

    ReplyDelete
  57. @Jim Rootham. God! Do you have pictures or something we can reference?

    I'd like to create some sort of wiki with all the info about SCM. It would be really fun, don't you think so?

    ReplyDelete
  58. Another one missing is StarTeam, from Borland:
    http://en.wikipedia.org/wiki/StarTeam

    ReplyDelete
  59. Rational CMVC anyone (1990ish) or is that a little too obscure for anyone else? It had views based on activities and only ran on Rational's own R1000 hardware, although it did turn up later on Suns.

    ReplyDelete
  60. Could you please add Jazz Source Control (included with Rational Team Concert) and explain how it compares to the other DVCS systems?

    ReplyDelete
  61. Normal files in VMS were versions controlled..

    ReplyDelete
  62. RCS probably does belong under "pre-history", but SCCS needs to be there too...

    ReplyDelete
  63. How on earth did you miss SCCS? Where source code checks in, but it doesn't check out. You need to revise the diagram.

    ReplyDelete
  64. @anonymous "How on earth did you miss SCCS? Where source code checks in, but it doesn't check out. You need to revise the diagram."

    XDDD


    Sure, I need to... But guys, the diagram space is limited!!! :P

    ReplyDelete
  65. Anonymous said about DSEE: "It died after HP bought Apollo."

    True. I was part of the original ClearCase dev team, though not an Apollo-DSEE person. The story my colleagues told me was that Dave Leblang, the "godfather" of DSEE, went to his new HP management and said, "let's port DSEE to HP-UX". They said no, so Dave took 5 engineers with him and started Atria.

    (At the time I came on board, the company was called Millennium TeamWare. But the name was soon changed: "two L's, two M's, two N's, too hard!".

    ReplyDelete
  66. What about http://jazz.net/?

    ReplyDelete
  67. CVS has a distinct weakness when it comes to merging: it does not record the event, so it tends to re-play integration errors that have already been resolved.

    Wierdly, this is fixed in CVSNT, which is a port of CVS to Windows that has since been backported to UN*X. CVSNT also automatically resolves trivial conflicts (i.e. identical edits) in two branches.

    That's about the only thing that CVSNT does right though.

    ReplyDelete
  68. @Matt Rickard: thanks for the remarks about CVSNT!!

    ReplyDelete
  69. And of course Panvalet - I used it on mainframes in the 1970's and it seems that it is still in use. Really nothing like a modern system, at least last time I used it, but it was better than boxes of cards. :-)

    ReplyDelete
  70. And even I new one mentioned in the slashdot comment thread: BOAR http://code.google.com/p/boar/

    ReplyDelete
  71. @Tim Panvalet??? Wow!! Not this is getting nearly complete guys!! :P

    ReplyDelete
  72. What about OpenCM which was a DVCS and focused on security and encryption. http://www.opencm.org/

    ReplyDelete
  73. The cell phone comparison is deeply, deeply flawed. Grep was written in 1973, does that mean I should stop using it because it predates even the biggest brick on the list?

    ReplyDelete
  74. @Devon Jones. Yes, you MUST stop using grep because it is a cool tool and it doesn't deserve such a pointless user...

    Now seriously: my goal was to highlight how some tools that are still in use and aren't good at all (grep is a great tool, CVS is not anymore!) comparing them to old cell phones. Just that.

    Linux, Windows, and even the BSD core behind every Mac are all old software but evolving software. CC, for instance, is not evolving, CVS isn't evolving either, and (not like grep) they're not cool or good anymore.

    Did I make myself clear? :)

    ReplyDelete
  75. Maybe I missed this, but what's the y axis?

    ReplyDelete
  76. @saurabh: No, I didn't mean to draw anything on the Y axis, just wanted to have some room to put all the names... :P

    ReplyDelete
  77. Without DSEE, this timeline is frankly, ridiculous. Sorry. It's like a history of western civilization without Rome.

    ReplyDelete
  78. You forget probably one of the most advanced of all of these: ENVY developer.

    OTI's ENVY developer let you write distributed crazy branching code quite easily and was more sophisticated than git or these supposedly more advanced tools.

    ReplyDelete
  79. I will also mention that you are missing monotone. I consider monotone to be a key DVCS because it pioneered the idea of a changeset hash, which is the breakout idea that makes all the modern DVCSes aside from Darcs work.

    monotone is slow and has some other problems and I would generally not recommend it. But as the initial instance of a vital idea I think it's an important part of any history of version control systems.

    ReplyDelete
  80. VSS was a funny one actually. It was the first version control system I encountered, back in the 90s, and it was actually really damn easy to use, but oh god did it bring the pain sometimes.

    I heavily evangalized its use at work because we really where losing code and had no real organizational clue.

    The boss at first hated it, "What was wrong with just using the file system?" he'd ask, and kept that attitude until we rolled out an update that was utterly borked, and I was able to pull up the changes in the relevant files and pretty quickly work out how we had fucked it.

    After that he wanted EVERYTHING in it, including all the correspondance, which it was terrible at (obviously).

    And then one day the server crashed and we lost it all. Yeah, we didnt have backups.

    ReplyDelete
  81. Does anyone remember BCS? (Baseline Configuration System.) We used to use it as an add-on to CVS. It used links to shared files in a baseline checkout unless you were editing the file. Complete nightmare! It seems to have disappeared without trace now though.

    ReplyDelete
  82. Why is Teamware not on the picture, when it is mentionned in the Bitkeeper description ?

    ReplyDelete
  83. While SVN of course has its limitations, the section about it here is over the top in its portrayal, especially when looking at SVN in a post-1.5 era (ie., merge tracking). It reads more like a commercial (for git, oddly... not plastic).

    As well, continuous integration as a practice goes well beyond trying to get around 'limitations' of SVN (or any other SCM tool).

    ReplyDelete
  84. CVS was originally cli only. Now I am going to be lazy and not look up when the client server feature was added. :-) It was magic when a small team used it as originally designed, but sure feels kludgey used in a client server styley.

    ReplyDelete
  85. I did not see any mention of Dimensions which is the newer evolution of PVCS.

    I have been working with Version Control Tools for 11 years, 6 of those years specifically with the job role of Software Configuration Manager. I manage SCMs for a development force of ~450 developers across a global enterprise with developers in US, China, Poland and the UK. I can honestly say that SVN does not suck. I have worked extensively with PVCS, VSS, CVS and SVN. I can say by far SVN is the best of those. I have found that a well followed and defined process established for how a development team functions overcomes the branching/merging issues. Yes, if you have no plan and it is a free-for-all, conflict resolution in SVN when merging would be a nightmare. So, if your development model/team is not mature in its process of how things are done, then yes, I can see how you would have a poor experience with SVN. But, pound for pound, it is an incredible tool that is very capable for handling the integrated and concurrent development models of a large enterprise. SVN also integrates extremely well with TeamForge (a.k.a. SourceForge) for coupling with project management (docs, tasks, issues, wiki, file releasing, etc) and the new HPQC Version 11 (ALM) for Test Case Management and with Automated Build Tools such as Hudson. Not sure how well the other Version Control Tools provide integration to these other technologies. That is one thing lacking in this article is how these different version control tools integrate with other technologies. Personally, a version control tool is not very valuable if it can not integrate or be used in conjunction with automated technologies and project management capabilities of a company. Sure, if you are a single developer or a small team, probably any Version Control Tool would work, but not if you are a large company. I have heard good things about Git. Seems better for the open-source free-for-all. I personally as someone who is responsible for the intellectual software of a major company to ensure all deliverables are repeatable and supportable, I get a little concerned when I see technologies that just allow anything. Sometimes with too much freedom, actually comes the pain of incosistency and discontinuity. Overall, good article and I enjoyed the comments most. And I will certainly agree, CVS...run away from it. Actually to migrate to SVN is a simple migration compared to going to other Version Control Tools because the CLI interface feels very similar. If you are using PVCS, go to Dimensions and if you are using VSS, then I am sorry. For the sake of all that is Holy, please try another tool. And one last comment, CA (www.ca.com) has a Version Control Tool called CASCM. My company is investigating it currently and I am responsible for evaluating the tool. Adds a lot of control/governance capability and has a visual feel like PVCS. It looks to be administratively heavy, but if you have a very mature process and strict governance requirements, it looks to be very valuable for that. Also, if you purchase their entire suite of products, it will integrate well. Not sure yet how it will integrate with other technologies.

    ReplyDelete
  86. Others have commented on SCCS. Let me just add that in 1982 (I think) I was a reviewer of Tichy's original paper on RCS. It was basically an extended argument that RCS improves on SCCS.

    Excellent post, by the way!

    ReplyDelete
  87. @Anonymous said...
    "Let me just add that in 1982 (I think) I was a reviewer of Tichy's original paper on RCS. It was basically an extended argument that RCS improves on SCCS."

    Wow!!! Thanks for the remarks!

    I thought I should extend the original post to include the comments but honestly I think now it is better if people can just read what you all have added! Thanks!

    ReplyDelete
  88. Don't forget CMS
    http://vms.cc.wmich.edu/www/vms_software.html#CMS
    It was only available on VMS (now on OpenVms). It was full featured and had a great command line and X-Windows interface

    ReplyDelete
  89. @anonymous: Re: I did not see any mention of Dimensions which is the newer evolution of PVCS.

    First, thank you for your comments. They are very fair and you bring up CA as well as Dimensions, that we failed to cover in this timeline. I think the general comment on SVN when looking at what you’ve used in the past, is accurate. SVN is better than CVS, VSS, and PVCS. But at the end of the day, our belief and experience tells us you went from no real branching and merging to a tool that does it marginally “better”. Refactoring is still broken in SVN. The history and timeline for SVN is really amazing. If you go back far enough, less than 3 years ago you'll find excerpts about what SVN can and cannot do with respect to merging. It would be unfair to say it doesn't do merging. It always was able to. But the underlying issue was that it wasn't designed for "merge tracking" until 1.5 was released. But for anyone that relies on merging, it's vital and deeply important. Merging was thought of as a cheap operation and simply redo it again. That's why merging is still broken and refactoring will always be an issue in the enterprise for SVN. I worked at a former company that developed SVN. I know of a large banking company that spends more than $1M annually on operational costs to manage SVN. And another company that creates military aircraft that utilizes both ClearCase and SVN and has said their operational costs for SVN almost equal what they pay in CC maintenance. But is SVN better than CVS, PVCS and VSS? Hands down it's better than those 3 tools. But there are far better tools out there over SVN and if you're spending a large amount on operational costs, you have the wrong tool. Although Dimensions is far more superior than PVCS, the upgrade path is EXPENSIVE and HEAVY. It’s a totally different platform. So if you’re already using PVCS and you’re going to spend money, you may as well look at other commercial tools or OSS. Going from PVCS to SVN is painful...no migration tools and all you get is slightly “better” branching and merging...it’s not superior. BTW someone developed a migration tool pvcs2svn, but if it was that easy of a migration to go from PVCS to SVN, then why isn't the SVN vendor supporting it and offering consulting services? It's also worth pointing out that CA uses ClearCase and at a time, they used it to develop CCC_Harvest (I'm sure it was a low percentage, but this was disturbing), which CA still has today. If you are investigating their new solution, ask them if they drink their own champagne. I interviewed at CA a few years back and quickly dismissed them when I learned about them using CC.

    ReplyDelete
  90. @anonymous: Re: I did not see any mention of Dimensions which is the newer evolution of PVCS.

    First, thank you for your comments. They are very fair and you bring up CA as well as Dimensions, that we failed to cover in this timeline. I think the general comment on SVN when looking at what you’ve used in the past, is accurate. SVN is better than CVS, VSS, and PVCS. But at the end of the day, our belief and experience tells us you went from no real branching and merging to a tool that does it marginally “better”. Refactoring is still broken in SVN. It would be unfair to say it doesn't do merging. It always was able to. But the underlying issue was that it wasn't designed for "merge tracking" until 1.5 was released. Merging was thought of as a cheap operation and simply redo it again. I worked at a former company that developed SVN. I know of a large banking company that spends more than $1M annually on operational costs to manage SVN. And another company that creates military aircraft that utilizes both ClearCase and SVN and has said their operational costs for SVN almost equal what they pay in CC maintenance. But is SVN better than CVS, PVCS and VSS? Hands down it's better than those 3 tools. But there are far better tools out there over SVN and if you're spending a large amount on operational costs, you have the wrong tool. Although Dimensions is far more superior than PVCS, the upgrade path is EXPENSIVE and HEAVY. It’s a totally different platform. So if you’re already using PVCS and you’re going to spend money, you may as well look at other commercial tools or OSS. Going from PVCS to SVN is painful...no migration tools and all you get is slightly “better” branching and merging...it’s not superior. BTW someone developed a migration tool pvcs2svn, but if it was that easy of a migration to go from PVCS to SVN, then why isn't the SVN vendor supporting it and offering consulting services? It's also worth pointing out that CA uses ClearCase and at a time, they used it to develop CCC_Harvest (I'm sure it was a low percentage, but this was disturbing), which CA still has today. If you are investigating their new solution, ask them if they drink their own champagne. I interviewed at CA a few years back and quickly dismissed them when I learned about them using CC.

    ReplyDelete
  91. svn is an awful tool. After using a DVCS using svn feels like going back to programming in BASIC.

    Perhaps SVN has worked well for you in the past. I know it has for me. But its time to upgrade your skills and knowledge. Try out Mercurial (I think it's tons easier to use than git, don't fall for the hype) or git (if you think peer pressure is a good basis for a technical choice). I bet after working with it for awhile you too will never want to go back.

    All the stentorian utterances about 'corporate control' and such are just coverups for being afraid of a new technology. I have more control with Mercurial than I ever had with Subversion. I can plain old reject changesets that the developers send me if they aren't good enough, and make the developers fix them and send them to me again until they're right. I could never have done that with Subversion.

    ReplyDelete
  92. I actually liked VSS - best user interface by far, back when source control wasn't integrated into IDE's.

    TFS is quite good. If it runs slow you need better hardware and the latest version. Nothing else integrates so much functionality in one place, the entire software development lifecycle.

    ReplyDelete
  93. I still have to use (suffer from) RCS on AIX... I didn't know it was *that* old ha ha but one can certainly tell y using it...

    ReplyDelete
  94. @Fred RCS on AIX sounds like the one to win the prize!! :)

    ReplyDelete
  95. Devon Jones, apropos your point about grep (two names of old Unix tools in one sentence) ...

    Just to reinforce Pablo's response, it's all about software evolving -- good ideas built upon other good ideas. I still use grep (on Windows, no less) all the time, but I also appreciate its evolving into the "interactive grep" feature of the free Notepad++ text editor. You get your grep results in a separate window pane, and each line of the results is a link, enabling you to jump to the location within the file.

    ReplyDelete
  96. Adding a (perhaps obscure) old SCM to the heap: Cadence Team Design Manager. (*shudder*)

    That heap of code takes the centralized model a step further. When you submit your files, they await "integration." Then an integrator can integrate your submit and make a release. It tackles branching and merging with all the grace of a DoD requisition procedure.

    To make a quick change and get it released, the SCM five steps, not including your update:

    -- Check out a writeable copy. This gives you exclusive access to the file.
    -- Check in your updated version. This releases your exclusive write lock.
    -- Submit your change. This doesn't make your change the official version yet, though.
    -- Someone with integration privileges now must integrate your change.
    -- The integrator now releases your change. It's now visible to everyone else once they update to the new release.

    Wheeee..... Oh, and your local "workarea" doesn't actually get copies of the files. Rather, TDM makes symlinks back to the canonical versions for your current release (unless, of course, you've checked out a writable copy). You can imagine the various and sundry ways that can break...

    ReplyDelete
  97. You should give a try with the SCM provided with Rational Team Concert. You can suspend your last changes to fix an emergency issue. You can create your own baselines and decide which one you want to share with your team. All your work is automatically checked in on server in a space assigned to you. You can either deliver your code to your team or ask to your peer to access to the changes of your airspace for review. I used several SCM in my developer life, I have to admit that this one is a topgun!

    ReplyDelete
  98. You forgot StarTeam, which I encountered at my last job at the Dept of State. Yes, they're still using it.

    ReplyDelete
  99. Nice summary, but I would also talk about security and the time when those Chinese hackers tried to attach Google by injecting code into its insecure Perforce repository. By the way, do they still use it or do they just firewalled it off the outside world?
    -Martin-

    ReplyDelete
  100. It seems you miss cpold in the list (reference : http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre-verte-du-suivi-de-versions.html in french) ;-)

    ReplyDelete
  101. Another obscure one, I once used: Aide-De-Camp from 1984. Far more powerful than RCS etc. However when I was I using it (early 90's) it was too slow.

    Cheers
    Mark Levison
    Agile Pain Relief Consulting

    ReplyDelete
  102. My first version control system was called UPDATE, available on the CDC6600 and later Seymour Cray origin systems. Circa 1969.

    ReplyDelete
  103. You state that VSS was entirely graphical, which is incorrect. VSS always had a full command line.

    ReplyDelete
  104. At my previous job, we used Visible Razor, a commercial product which was very much a client-server tool which only allowed one user to check out a file at a time. It did have one feature which my company used, every check out or commit of a file needed to have an issue (from the integrated issue tracker) associated with it.

    ReplyDelete
  105. Biggest missing ones from my career (but mentioned be others in comments) :-

    Microsoft Delta - A commerical product before they released before VSS in early 90's. Worse than VSS.

    StarTeam - Fairly decent product by borland.


    CVS and Subversion are pervasive and effective as long as you don't want to branch and merge much.

    Clearcase is a horrendous beast, allegedly potentially very powerful but incredibly expensive and never seen it set up in a usable state. Whatever strategy adopted it seemed buggy or poor performing. Dynamic views perform horribly over network. Check ins can be non atomic. Snap-shot views fast but out of date. Auto-merge functionality can result in the wrong code going into SCM.

    ReplyDelete
  106. Biggest missing ones from my career (but mentioned be others in comments) :-

    Microsoft Delta - A commerical product before they released before VSS in early 90's. Worse than VSS.

    StarTeam - Fairly decent product by borland.


    CVS and Subversion are pervasive and effective as long as you don't want to branch and merge much.

    Clearcase is a horrendous beast, allegedly potentially very powerful but incredibly expensive and never seen it set up in a usable state. Whatever strategy adopted it seemed buggy or poor performing. Dynamic views perform horribly over network. Check ins can be non atomic. Snap-shot views fast but out of date. Auto-merge functionality can result in the wrong code going into SCM.

    ReplyDelete
  107. Biggest missing ones from my career (but mentioned be others in comments) :-

    Microsoft Delta - A commerical product before they released before VSS in early 90's. Worse than VSS.

    StarTeam - Fairly decent product by borland.


    CVS and Subversion are pervasive and effective as long as you don't want to branch and merge much.

    Clearcase is a horrendous beast, allegedly potentially very powerful but incredibly expensive and never seen it set up in a usable state. Whatever strategy adopted it seemed buggy or poor performing. Dynamic views perform horribly over network. Check ins can be non atomic. Snap-shot views fast but out of date. Auto-merge functionality can result in the wrong code going into SCM.

    ReplyDelete
  108. After almost 25 years in this game the one thing that never seems to change is the number of people that talk out of their ass, get all passionate about the last tool that worked well for them, and move like monkeys toward shiny objects when the next new cool tool comes out.

    The bottom line is that there are, and for a number of years have been plenty of good SCM solutions out there, and great new ones being introduced all the time. You just have to pick the one that's adequate for the job and do your homework when it comes to implementation. But the tool is only part of the solution. Good tools coupled with shitty process will give even the best tools a bad reputation and there's a lot of shitty process out there. You need good process to make good tools effective.

    ClearCase, for all its faults was an extremely powerful SCM tool. Yes, it didn't have atomic commits, but you could implement them if that's the way that you wanted to work. It branched files and directories individually, but there was tremendous power in that model if you wanted to take the time to understand it and you could mold it to work however you wanted it to. There are plenty of traps, and ways to shoot yourself in the foot, but properly implemented, you could have hundreds of developers in multiple locations using it efficiently. I know because I've done it several times. My last deployment had over a hundred users across four locations with two people maintaining it and the build system.

    There's no question that ClearCase is long in the tooth, its design assumptions antiquated and its cost unjustifiable in a world of very high quality and capable open source tools. There's also no question it's time to move on to better, more cost effective tools with simpler models and less overhead. But ClearCase, and I'm sure others would argue, many of its equally antiquated and long in the tooth peers, managed, and in a lot of cases still manages many millions of lines of code for thousands of applications around the world. Its days of a "best of breed" application are gone but its branching and merging capabilites are extremely reliable and its foundation is built on more than 20 years in production for some of the worlds largest software development organizations.

    One final note. A poor branch and merge strategy with even the best tools can still result in fucked up code. Anyone claiming that ClearCase can't branch and merge correctly has either never used it, were subjected to a poor implementation, or just didn't know what they were doing.

    ReplyDelete
  109. Great Article!
    I want to hear how do you think about features of versionized asset management systems such like Alienbrain or BAM(*1) from SCM view.
    personally I think per-file dependency tracking can be next wave of SCM.

    *1
    http://gooseberry.blender.org/bam-building-the-asset-manager/

    ReplyDelete
  110. I have one major/huge correction, but before I do I have to say the resulting article at this point in time is pretty darn good+complete. And the commenters pretty much filled-in history of some of the other noteworthy historical SCMs.

    Okay - the correction I have is this: Task-branches and feature branches are *completely* *different* *things*. Please do not equate them - they are NOT at all synonymous. Task-branches were always for short-lived development tasks, whereas feature-branches were for *big* features that served as a separate integration codeline for a separate feature-team. Short-lived task-branches are *still* a oft-recommended practice today (even tho "short-lived now means even shorter scale, as in hours or a whole day, rather than several days)

    A few key embellishments of historical note ...

    - Aide de Campe is worthy of mention because its creator, Richard Harter, was the one who coined the term and concept of a "change-set", and in fact CM Synergy (formerly Continuus, and before that "Amplify Control" and initially created by Martin Cagan) used something called a "change package" which was a different implementation of a similar concept, and the difference between the two was the subject of much debate in the SCM community until the term "change-set" finally won out as name of the key concept, with the variations in implementation being less important (despite some noteworthy pros/cons/tradeoffs). Oh - and Damon Poole (creator of Accurev) was a developer for Aide de Campe (ADC) in the mid-80s.

    - If we look at the PC (DOS), the first "real" version control tools there (circa mid-1980s) were basically ports of RCS (which is what MKS, and PVCS started off as), a port Softool's "CCC" called "Harvest", PVCS (rewritten), Tlib (from "Burton Systems"), and SVM (Seidl Version Manager). I was a developer of SVM in the mid-80s, before it was acquired by the makers of PanValet (VCS for IBM mainframes), and rebranded as a PC client of Panvalet. Then later acquired by Computer Associates (who had previously acquired Polytron & PVCS, before it merged with SQL Software and PCMS to become PCVS Dimensions)

    ReplyDelete
    Replies
    1. Thanks for the remarks, Brad.

      So honored to count on your contribution to our blogpost :-)

      You are totally right with the feature/task branch confusion, no excuses since we even explain the difference very often to developers: http://blog.plasticscm.com/2017/04/trunk-based-development-blends-well.html

      Delete