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

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