Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

An Illustrated Version Control Timeline 244

Posted by CmdrTaco from the remember-when dept.
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."
This discussion has been archived. No new comments can be posted.

An Illustrated Version Control Timeline More

An Illustrated Version Control Timeline

Comments Filter:

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) * on Wednesday November 17, 2010 @01:00PM (#34256990)
    Comment removed based on user account deletion

    • Finally, i'll go out and say it, the hate-on for SVN is overrated. A part from a few world class developers who, for some reason, have shitty network connections and thousand patches to sort though, it's mostly cool-kids overcomplicating their lives solving "problems" they never had while developing their blogging software, not working in an office, and imagining they are Linus Torvalds?

      While I agree svn isn't bad to work with, having a local repository can be VERY handy once you're accustomed to the workflow.

      Enough so that when dealing with svn repositories it's rather nice to be able to import a complete copy of the repo using git-svn, albeit it takes somewhat longer etc.

      With svn I could not do version control based things during a long commute such as finding out who wrote a specific line of code so I can make a note to yell at them, with git I can. One of many things.

      • Re: (Score:2, Informative)

        by dannys42 ( 61725 )

        I agree, subversion is not terrible. However, after getting a laptop, I definitely see the advantages of a DVCS. git's not the friendliest of tools, but regardless of the reason, there's a lot of moment out there and supporting tools, so I prefer using git as my DVCS system.

        In addition, with git, I also have gotten extremely comfortable with creating a new local branch for any separate task I want to do. This makes my commits much cleaner and virtually eliminates the problem I had with svn where I was wo

      • Re: (Score:2)

        by e4g4 ( 533831 )

        While I agree svn isn't bad to work with

        SVN is barely tolerable. I'm never going back - git is so much better it's not even fair to consider it in the same league as SVN.

        • Completely agree that git is leagues ahead, but svn is usable in the sense I could use ed as my ide if I wished, while nowhere near as useful it is still functional, for a certain need.

      • Re: (Score:2, Insightful)

        by WuphonsReach ( 684551 )
        The better way to look at a lot of the SCM systems boils down to:

        - How technical are your users?
        - Do you want something centralized or decentralized or a mix?
        - What tools do you have and do they play nicely with the SCM?
        - Does the SCM play nicely in your environment?
        - Is the product worth the licensing cost (vs a free solution)?

        For instance, SVN is definitely better then CVS, but it's centralized. Which has some advantages and disadvantages. It has very nice tools (TortoiseSVN, FSVS) and is easy f

    • Re: (Score:2, Insightful)

      by C3c6e6 ( 766943 )

      I couldn't agree more. In my previous job, I had a colleague who wanted to convert me from SVN to Bazaar (http://bazaar-vcs.org/).

      He told me "it was very simple to use, you only have to..." and then started drawing a very complicated diagram on my whiteboard.

      Personally, I thought it was complete overkill for the two-man project we were working on.

      • Actually Bazaar and Mercurial do work with the much simpler feel of RCS in that there is no real effort needed to set things up. It can be refreshing to not have to mess around with repository configuration for simple projects.

    • Re:My god, it's full of troll. (Score:5, Interesting)

      by mikestew ( 1483105 ) on Wednesday November 17, 2010 @02:24PM (#34258630) Homepage

      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. (Score:4, Insightful)

      by julesh ( 229690 ) on Thursday November 18, 2010 @03:28AM (#34265898)

      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)?

  • Arcane CVS and what not (Score:3, Insightful)

    by discord5 ( 798235 ) on Wednesday November 17, 2010 @01:01PM (#34257008)

    There are teams out there developing iPad software and checking in code inside arcane CVS repositories

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

    • Re:Arcane CVS and what not (Score:5, Insightful)

      by glwtta ( 532858 ) on Wednesday November 17, 2010 @02:16PM (#34258490) Homepage
      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: (Score:2, Troll)

        by farnsworth ( 558449 )

        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.

        Also, OS X ships with svn, but not cvs. I'm not sure that if you install the dev tools if that will install cvs, but I tend to doubt it.

        • Re: (Score:2)

          by jeremyp ( 130771 )

          My OS X install definitely has CVS although I'm not sure if it came with the OS or the dev tools.

          • My OS X install definitely has CVS although I'm not sure if it came with the OS or the dev tools.

            I just picked up a mac last Friday, and I haven't installed the dev tools yet. It has svn, but not cvs. Older versions used to ship with cvs, IIRC, but not for a while. If you do an OS upgrade or migration assistant setup through the years, it's likely that cvs will be installed. But OS X does not ship with cvs anymore.

      • Re: (Score:2)

        by jgrahn ( 181062 )

        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.

        I have all of my code in CVS and I trust it; I've personally seen it work every day for the past twelve years. I share some repositories with my brother, who's less inclined to learn a new tool. Sticking with CVS is a no-brainer for me.

      • Re: (Score:2)

        by syousef ( 465911 )

        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.

        I did a large CVS to SVN conversion earlier this year. Do you have any idea how many scripts had to be changed and what kind of testing had to be done? Drop in replacement my arse.

  • Meh. (Score:3, Insightful)

    by HeckRuler ( 1369601 ) on Wednesday November 17, 2010 @01:06PM (#34257078)
    Geez, he's right, I've been using things like grep and gcc just because I'm familiar with them and they perform the task at hand. Time to upgrade to the hip and new version that does the same damn thing in a slightly different way!

    Not that I'm against progress, but it's a matter of weighing the hassle against the gains. Forcing the new kids to learn the old tools can be annoying, but good for them. Likewise, showing grandpa that there's a diff with side-by-side comparisons is probably a good idea.

    • Re: (Score:3, Interesting)

      by Short Circuit ( 52384 )

      Geez, he's right, I've been using things like grep and gcc just because I'm familiar with them and they perform the task at hand. Time to upgrade to the hip and new version that does the same damn thing in a slightly different way!

      Not that I'm against progress, but it's a matter of weighing the hassle against the gains. Forcing the new kids to learn the old tools can be annoying, but good for them. Likewise, showing grandpa that there's a diff with side-by-side comparisons is probably a good idea.

      Don't forget bitrot. Enough other people move to $new_tech, and those of us who were productive with $old_tech suddenly see things break.

  • Welcome to hell (Score:2, Informative)

    by Transfinite ( 1684592 )
    We use TFS here. Because some suit that shouldn't have been making the decisions he did, who was also probably wined and dined by some MS suit. Was told it was the best thing since sliced bread. Every developer to a man hates it. It sucks. god knows how much this 'privilege' costs us.

    • Re: (Score:2)

      by Tridus ( 79566 )

      TFS is actually tossed in with every MSDN subscription now. So if you're in a shop that pays for MSDN, then going to TFS didn't cost you anything in terms of the software. For small .net shops, its actually pretty convenient since you also get issue tracking, test tracking, and a bunch of other stuff tossed in at the same time.

      I had Codice pitch PlasticSCM to me once. It was interesting, but for what we were doing there was nothing in there that particularly mattered and thus the price couldn't be justified

    • God's not the only one that knows, I was responsible for pricing it last place I was at. First, it's old-school enterprise pricing as I could barely figure out how much it would be for our shop, let alone yours. Figure about $500US for client license, $3K for the server.

      It's actually pretty damned good for bug and project tracking, and keeping it all tied together. If your manager's any good, just forget status reporting as it can all be pulled from TFS.

      But in the context of source control, TFS sucks ass. S

  • Speaking of modern CVS repositories, one thing I haven't seen is version-ing for web based applications and sites. The one I use is a custom job built by our corporate office and it works very well but it's missing a lot of features. Every once in a while I google for any projects like this and haven't had anything turn up. Anyone know of any?

    • What special needs does a website have for versioning that isn't covered by the usual tools?

      • I guess not a whole lot, honestly... but our custom job keeps a development, staging and production version of our code, each that has it's own versioning and is sort of like it's own site, but doesn't have all the nice stuff from a full cvs like diffs and patching. I think that this functionality could probably be done with some bash or perl scripts to move the files around for you. I did see though that sparkfun.com used subversion and is now using git for their sites code base, so maybe your question has

        • You can just have different branches, and then use git push to update the production branch on the server's repository.

          • Interesting, that makes sense, I think I may try setting up a theoretical system like that. Thank you for your advice, good sir.

      • Ah, I've been dealing with this extensively recently.

        Web development is sometimes not done locally as application development. Without a file synchronization utility you practically have to work on the dev server if you want to see your changes immediately (edit file, save, refresh page.) There is a plugin for Eclipse that that will sync files on save, but it's a one way copy and if anything changes on the server (from another team member) your file sync will copy your version of that file up overwriting

    • I'm not sure what you mean by "version-ing for web based applications and sites"

      I have SSH access to my web host.
      The web app code resides in a remote Git repo on the server.

      This is how I update my web based application.

      git checkout remote-master
      git merge local-changes
      git push

      • No that makes sense, but for our major site there's three different versions of basically the same code base as a development, staging and production. But icebraining pointed out to me that I could keep three different branches. I've never been at the top level planning stage for large projects so I've never thought out and set up a cvs system for a project. I've only ever been a user. To be clear I don't have say so over the major site that I work on anyway I'd just like to understand the process I guess.

    • So, you'd like some kind of Web Distributed Authoring and Versioning tool? I wonder if there's anything out there which would do this thing; a good name for it would be WebDAV. Why, they would even register http://www.webdav.org/ [webdav.org] for information! ;)

      Seriously, this is the protocol Subversion uses if you use the apache module. It works well. And if you look for information on managing a web site with subversion, you'll likely find quite a few examples of doing exactly what you're asking for in later comme

      • Haha, I should probably be red faced but instead I'm grateful. After reading through the page a bit that's exactly what I'm looking for... Duh. XD Thanks for clue-ing me in!

  • I'm stuck using SCCS [wikipedia.org], you insensitive clod!

    • Re: (Score:3, Funny)

      by blair1q ( 305137 )

      Stuck? You're probably the least stressed of us all. Using sccs is the code-control equivalent of moving to Napa and buying a vineyard.

  • Too Many Acronyms
  • If it's anything like Hudson's graphical build timeline, it's a cool feature that made me go "neat" but I have honestly never used it to look stuff up on our CI server.

  • Source control is so political (Score:5, Insightful)

    by MobyDisk ( 75490 ) on Wednesday November 17, 2010 @01:16PM (#34257260) Homepage

    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.

    • Re: (Score:2)

      by blair1q ( 305137 )

      Because this one piece of software is ingrained in the company's quality process. With most tools, if you use something different, nobody cares, they're just glad you're getting your work done. With CM, you have to use the same tool everyone does. When you start proposing to change that tool, everyone has a stake in it, and an opinion of it, and of your opinions.

      And this is mild. Can you imagine if everyone had to use the same editor [wikipedia.org]?

    • Re: (Score:3, Informative)

      by MobyDisk ( 75490 )

      P.S.
      - One company used their own internal source control. That was by far the worst.
      - All the small companies and contracts used either perforce or svn.

      Just pointing this out since I meant to contrast the relationship between company size and tools.

    • Re: (Score:2)

      by slapout ( 93640 )

      Because at some point you have to pick a product and go with it if you want to get work done. Sure you can reevaluate every so often, but you can't spend all your time constantly upgrading to the latest thing. People are given a tool, they learn it and get work done.

    • Re: (Score:3, Interesting)

      by WuphonsReach ( 684551 )
      I don't know why this one piece of software evokes such illogical responses. Oh well.

      Well, unless you're completely insane, you don't change SCMs more then once a decade. Entire processes get built around the current SCM (QA, deployment, development, archival, etc) and that's not something easily changed.

      So it's never as simple as swapping one command for another. The thought processes are slightly different, everyone has to update their workflow or custom-written glue tools and you may lose version

    • Re: (Score:2)

      by l0b0 ( 803611 )

      Show, don't tell. git-gui, TortoiseSVN, gitk, Trac+Git plugin, git interactive rebase. Then demonstrate the awesome speed of a DVCS to someone who does hundreds of commands per day - It'll blow their minds.

  • Advertising disguised as history lesson. (Score:5, Interesting)

    by fahrbot-bot ( 874524 ) on Wednesday November 17, 2010 @01:23PM (#34257438)
    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.

    • But git is faster [contextual...opment.com], so there are reasons to use it even if you don't need the new features.

      • Re: (Score:3, Insightful)

        by fahrbot-bot ( 874524 )

        But git is faster, ...

        Yes, given the example on your link, if I ever need to checkout the *entire* FreeBSD repository, I'll think of GIT. Otherwise, I'm not losing much sleep over the speed difference. :-)

        From a practical standpoint, people will use what their employer is already using. Here, we mainly use CVS. There are pockets of SVN and (perhaps) GIT, but no one is interested in converting and, more importantly, retraining the users and rewriting the management/utility scripts.

        Another example, I

    • And SCCS was far from the first version control system. The major features SCCS introduced was automatic generation of the change files (thanks to diff) which made it much easier to use, and (made possible as a result) keeping the latest version as the "base" version, so applying the change files produced earlier versions, instead of later ones - that produced much better performance for the most common task, getting the latest version.

  • 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: (Score:2)

      by MobyDisk ( 75490 )

      Am I missing something, or is this all based on pre-1.5, when it didn't have merge tracking?

      AC replies with:

      in SVN it's something complicated requiring you too know the revision when you branched and other stuff, something like 'svn merge -r a:b ../../trunk' from inside the branch.

      19NervousBreakdown: I think the AC just proved exactly what you were saying. Everyone thinks it is hard because it was hard pre-1.5.

    • Re:Subversion branching and merging (Score:5, Interesting)

      by EvanED ( 569694 ) <evaned@g[ ]l.com ['mai' in gap]> on Wednesday November 17, 2010 @02:51PM (#34259188)

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

    • It becomes really ugly when you start refactoring code. Renamed and moved files are killer to merge. Even in 1.6, I'm afraid...

      • Re: (Score:2)

        by Entrope ( 68843 )

        Last time I used Subversion (1.4.something), renamed and moved files are killer to *review history for*. On one project, I had foo.c for a few hundred revisions, renamed it to bar.c, and many revisions later created a new foo.c. When I asked Subversion to show the content of foo.c as of revision 50 (the original file), Subversion claimed foo.c did not exist. As far as I could tell, it was trying to find the contents of the new foo.c as of revision 50. Hate.

      • It becomes really ugly when you start refactoring code. Renamed and moved files are killer to merge. Even in 1.6, I'm afraid...

        Yeah, one of the big things I wish SVN would have done from the start would have been to allow some sort of unique-identifier as an alternative way to identify a particular file/folder. So you could say svn://myserver/myrepos/UUID as a shortcut for referring to a file deep down inside some directory tree. From my cursory inspection of GIT, it's something that GIT seems to get r

    • Re:Subversion branching and merging (Score:4, Insightful)

      by JPyObjC Dude ( 772176 ) on Wednesday November 17, 2010 @04:12PM (#34260486)

      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: (Score:3, Interesting)

        by swillden ( 191260 )

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

        SVN is particularly excellent when you use GIT as the front-end. You get all of the super-easy local branching and merging, history rewriting and lighting speed of GIT for everyday use, and when you're ready to push your work to the rest of the team, you publish it to SVN.

        BTW, yes, SVN branching and merging has gotten much better since merge tracking was added, but it's still too slow and clunky for effective use with the "branch per feature" pattern of development. It can work, but GIT runs circles aro

    • Re:Subversion branching and merging (Score:4, Interesting)

      by Prien715 ( 251944 ) <agnosticpope@gmail. c o m> on Wednesday November 17, 2010 @05:21PM (#34261718) Journal

      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.

  • I was hoping for a visual timeline of distributed git repos, or something that would make using git easier. Git is likely a better way to do version control, but it is better because it is fundamentally different. Those differences have not worked their way into Eclipse's abstraction of version control far enough, yet.

  • For personal projects, I've mostly been happy running RCS on my own server. I use CVS from time to time, and bits of it annoy me, but I can get work done with it.

    Maybe for huge open source projects with teams all over the planet who can't communicate very tightly and who don't have a unified SDLC, some of these newer tools are worthwhile. But if you've got a small team and an adequate process, what's the compelling argument for switching to one of them if what you've got in place is working fine?

  • Horses for Courses (Score:2, Insightful)

    by dubious_1 ( 170533 )

    The author appears to believe that old version control systems are bad because they are old.
    I have used ( and administered ) projects using RCS, CVS, SVN, Perforce, Clearcase, Git and VSS.
    RCS - Advantage: no setup necessary. I used RCS to track changes to my 140 page thesis ( latex ) during the year of writing. I can still take that tar archive and extract to any workstation, PC ( windows, mac or linux) and have full access to the revision history. No setup, dirt simple. ( of course since RCS was never d

    • Re: (Score:2)

      by jeremyp ( 130771 )

      I think I'll take what you say with a grain of salt. I use svn most of the time at work and in my own projects and pretty much everything you say about it is wrong except that it is better than CVS. It has no distributed support out of the box but it has had locking for a good five years or more.

  • Ooh, PlasticSCM is free (as in beer, but not as in liberty) for up to fifteen users for a lifetime! Git is free. (period). Why do we even put these on the same chart?

    • Re: (Score:2)

      by Entrope ( 68843 )

      Someone up-thread nailed it: The blog post is really a not-very-stealth advertisement for that commercial SCM tool.

  • Their description of Subversion is almost blatantly wrong, and misses much of the improvements SVN brought about. It would have helped them to at least have read some of the Subversion Documentation [red-bean.com] - or even just the chapter on Subversion's Delta Editor in the book Beautiful Code [oreilly.com].

  • They're selling a VCS (Score:3, Informative)

    by Lemming Mark ( 849014 ) on Wednesday November 17, 2010 @03:52PM (#34260184) Homepage

    It's a nice timeline of some key milestones but it's worth noting that they're advertising something, it'd be nice if that had been clearer from the article.

    Also, I was disappointed not to see GNU arch / tla get a mention as I think they might have been first to decentralised operation. They were most certainly one of the first and as such I suspect they had a certain amount of influence on those that followed, even though the user experience was reputed to be lacking from what I heard (actually, I thought that bzr evolved out of it too, so it may also have a more direct connection with the modern-day main players)

  • I've started using Mercurial, and I LOVE it! It's lightweight nature means I can make ANY directory a repo, and keep track of changes within that directory, using nothing more than that directory. This makes it feasibly easy to use source control in places I never would have with SVN - such as admin scripts buried in /usr/local, or all the system settings in /etc...

    It has solved problems I never thought truly possible to solve instantly, easily, and accurately.

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close