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.

Re:Advertising disguised as history lesson.

[fahrbot-bot]

Hey, wasn't Linus Torvalds himself who said "you must be brain dead to use CVS"?? Don't shoot the messenger!

Linus is not a god and not everything he says should be taken as gospel. He gets a LOT of things wrong. Put down the cool-aid. :-)

Hey, I'm successful and independently wealthy too, and I like CVS. Quote that! :-) Now, I admit that I haven't extensively used most of the tools in the "article", but I haven't needed what they offer above and beyond CVS.

As for the cell-phone analogy in the "article", I still use a Qualcomm QCP-1900 cell-phone from 1998 and, surprise, it still manages to work great as a phone. Paid $200 for it outright (no contract), which works out to $16 a year and still have a $15/month no-contract account. I only need it to make phone calls. Sometimes, it pays to stick with what you have and what works...

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:Subversion branching and merging

[JPyObjC Dude]

I too have used Subversion since it was in pre-release (0.8) I think. When I started doing research on Source control, my managers said "Use VSS". I disliked MS at the time and still doo and thus avoided that path. I came across the thesis by the author of RCS (great read) and researched about RCS, PVCS, CVS and SVN. SVN was a dream come true when I saw it. Tortoise SVN was the icing on the cake. I have since continued to use SVN and have converted many others to SVN away from VSS and other tools. I love SVN still and use it daily and will not be switching any time soon.

Regarding the post, I don't really like hearing is that "All major open source projects" are moving away from SVN. Sorry but there are many still using SVN and will continue to do so. For instance FreeBSD, which is a huge project, who are still using SVN today. Also, saying that SVN is wrong is wrong. SVN is wrong for some groups but very right for others.

Also, people are constantly mis-reading Linus's comments on SVN. Linus was just dissing SVN for his uses and was tired of the evangelical SVNers nagging him to use it. I appreciate that his code models are different and require different SCM tools and that a SVN centralized model does not work. But this does not mean that SVN is wrong for everyone.

SVN is valid for many groups, teams, around the world and will continue to be so for the foreseeable future.

- JsD

Re:Subversion branching and merging

[Prien715]

I used SVN for the past 5 years and I thought branching and merging was a pain. Well, actually, I didn't think it was a pain, mostly because I didn't know any other way.

Then I tried Git. And Hg. I haven't looked back. TortoiseHg works great BTW;)

From a day-to-day workflow standpoint, I find I get far fewer merge issues when working with either tool; basically, you are forced to run an "svn update" before you can run an SVN commit. And unlike SVN, if you do a bad merge, it's much easier to go be back and redo. Additionally, if you merge 100 bug fixes from the "stable branch", both Hg and Git preserve the history of the bug fixes. So if you do "svn blame" the line that fixes the nasty stack corruption bug, you'll see "Fixed nasty stack corruption bug when doing X/Y/Z" rather than "Merged from stable branch". Yeah, you can go back and do detective work and figure it out with SVN, but don't you have better things to do?

Also, they've changed my entire workflow. With a distributed system, I'll commit code locally ("OK, this mostly works."). But since the feature isn't 100% done, there's no reason to put it in the main code tree for all the developers to look at. That way, if I manage to screw something up (say cause a nasty crash that corrupts the stack), I can update back to these prior "mostly working" revisions. SVN forces you to either create a branch every time you want to work on a feature (in which case, it's a pain to update from the trunk...merging your code back becomes painful), keep a bunch of uncommitted code, or commit 1/2 working code you'll finish later. With Git and Hg, I commit early and often.

Honestly though, try Git or Hg. That's the best way to see its advantages. I'm trying but it's like trying to explain the advantages of a high level language to an assembly language coder: the assembly coder is perfectly happy, but doesn't think he "needs" all these "fancy" features since he has no real concept what they mean.

I tried to convince people at my last company to switch, and it didn't happen. At my current one, I just said "trust me guys" to a bunch of more senior developers. We made the switch from SVN. I've been thanked numerous times by all of them.

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:pardon, your ignorance is showing

[icebraining]

DVCS can use the exact same workflow as non-distributed VCS, and they're faster in many cases - including not having to connect to a central server for each and every commit.
If it costs you to change now, don't, but if you're starting a new project, I see no reason to choose CVS.

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.

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

[julesh]

And another point: "the age of distributed version control"?

I work in an office. I have a gigabit network between my workstation and the version control server, which runs on a RAID array significantly faster than the disks under my desk. The connection is always on, always works, and is so fast I don't notice it. In what way could I possibly benefit from a distributed system? And why would I use a distributed system when every one I've ever tried requires a two-step approach to sending my changes to the other developers (synchronize my working copy with the local version control, push changes from local to the rest of the team) rather than just one (commit changes)?