An Illustrated Version Control Timeline

rocket22 writes "Most software developers are supposed to be using the latest in tech and see themselves as living on the edge of software innovation. But, are they aware of how old some of the tools they use on a daily basis are? There are teams out there developing iPad software and checking in code inside arcane CVS repositories. Aren't we in the 21st century, the age of distributed version control? The blog post goes through some of the most important version control systems on the last three decades and while it doesn't try to come up with an extremely detailed thesis, it does a good job creating a catalog of some of the most widely spread or technologically relevant SCMs."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

Source control is so political

[MobyDisk]

All of "big" companies I've worked for use ancient out-of-date source control. The first one used VSS (late 90's, so it wasn't so unusual at the time) but then around 2000 moved to PVCS. All the developers assumed that someone got kickbacks because there's no reason to move to an older, more expensive, inferior product. Now I work at a Fortune 500 company that also uses PVCS. Their reason: not a soul in the building has ever used anything else. I explain about the features of modern source control and people look at with with either marvel (it can do that!!??), or disdain (how dare you question my source control system).

I don't know why this one piece of software evokes such illogical responses. Oh well.

Advertising disguised as history lesson.

[fahrbot-bot]

First, the history/time-line is simply a lead-up to the plasticscm product.

Second, the article doesn't even mention SCCS, developed in 1972 (and still available), so his history lesson is lacking some completeness and perspective.

Third, remarking, "It [CVS] is outdated now, but it worked in the 90s! (If you have it, just walk away and go on to something else!)" -- as well as the other snobbish comments about other (older) systems -- is simply narrow-minded. CVS is completely satisfactory for many, many projects. Contrary to later comments in the article, I've used, and still use, CVS in several commercial products and it works just fine.

Real lesson: Newer is not always better; more features are not always needed.

Subversion branching and merging

[19thNervousBreakdown]

I hear all the time how terrible Subversion is at branching and merging, but I can't really see any issues with it. Am I missing something, or is this all based on pre-1.5, when it didn't have merge tracking? Granted, it was fairly brain-dead to not track what revision a branch occurred in or what revision it was last merged to a particular other branch (or the head), but as far as I can tell, comparing it to AccuRev which I use at work heavily and is supposed to be fantastic at merging (it's ... ok), there's little difference beyond the terminology.

Can somebody explain what it handles so badly? I feel like I'm not missing something I should be. I like Subversion, probably just because I know it, and use it for my home projects, but if there was an actual benefit (and decent cross-platform tools, TortiseSVN is fantastic, I love working on my linux box but doing graphical diffs on the same working copy over a Samba share) I'd love to switch to something better--I know I said I like Subversion, but it's more like how you like a kevlar vest, it's better than the alternative, which in this simile is bullet holes in my torso.

Re:Subversion branching and merging

[EvanED]

It's possible I'm missing some shortcut syntax or something, but just the Subversion syntax for creating a branch and merging is just terrible. Compare git checkout -b my-new-branch to either remembering the whole repository URL or running svn info and copying and pasting it, then running svn copy some://really.long/url/to/your/repository/trunk some://really.long/url/to/your/repository/branches/my-new-branch then svn switch some://really.long/url/to/your/repository/branches/my-new-branch. And merging is similar.

You can avoid this syntax by checking out the whole damn repository and using working-copy paths, but this has its own set of severe drawbacks (e.g. now your svn copy takes a long time).

These drawbacks are made smaller by Tortoise (which is awesome) since you can just edit the existing URL in the switch dialog, but it's still pretty darn ugly.

I like Subversion, probably just because I know it, and use it for my home projects, but if there was an actual benefit ... I'd love to switch to something better

I'd really encourage you to give Git a shot. Pick a project and use it for that project. It takes some getting used to, but it's not too bad, and once you are used to it it provides a number of really nice benefits even if you're just a single person working on your own projects. And there is a TortoiseGit that works well. (Just be aware that TortoiseGit attempts to hide what Git calls the index. This makes it act more like TortoiseSvn from your standpoint, but I did run into a problem once that was caused by mixing use of TortoiseGit and the command line git client in one repository.)

(From my own standpoint, I've heavily used all of CVS, Svn, and Git. I hate CVS with a passion, and for a long time thought that the improvements you get from moving from CVS to Svn were enormous in comparison to moving from Svn to Git. I still think this is true, but as I've used Git more and more, I think the Svn to Git change brought about rather more benefits than I initially considered even for single-person and centralized projects.)

Re:CVS May be Old, but...

[JerkBoB]

"If it ain't broken, don't fix it."

Right. And CVS is horribly broken. So it's been fixed. :P

Re:Arcane CVS and what not

[glwtta]

But does it work for them? If so, great! Why switch to something else if you have no real need for all those features?

It's not just about features, CVS is deeply broken (tagging/branching, directories, binary files, metadata, etc). Subversion is a drop-in replacement that fixes (most) of the problems and can be used in exactly the same workflow. The two are equivalent and one is less broken - it's kind of a no-brainer.

Re:My god, it's full of troll.

[mikestew]

Full of troll, and incorrect in some spots. For example, TFS doesn't do branching and merging? It may do a crappy job of branching and merging, but that functionality is prominently there.

I quit using SVN just because I found the Xcode integration to be flakey at best, and remote work was less than seamless. It otherwise seems to work fine, and what it lacks are things that are just poseur points for most shops (quick, list two problems for your shop that only a DCVS can solve).

Git worked for me when I was doing work on the bus to and from my day job, allowing granular commits instead of the big mixed-up commit when I got home. I like it for a lot of other reasons even after doing my own thing full-time. But there's no way I'd get on a religious soapbox about it, starting with the learning curve (first time a merge or a push goes wrong, break out the google).

But hey, use what you want as long as it's not VSS. Because even a tabs vs. spaces flamewar interests me more than source control debates.