Slashdot Mirror
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."
Comment removed based on user account deletion
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?
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.
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.
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.
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.
It must have been something you assimilated. . . .
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.
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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.
"If it ain't broken, don't fix it."
Right. And CVS is horribly broken. So it's been fixed. :P
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
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.
Dilbert RSS feed
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.
I'm mostly a single person team, and I find DCVS quite useful (the reasons I won't bore anyone with). For my workflow, centralized (SVN in my case) was limiting me.
Central machine with repo is down - nobody works.
They can commit locally many times and merge that to a single commit per feature before ushing to the central system.
Git uses much less space than SVN - Mozilla's repo size: CVS - 3GB, SVN - 12GB, Git - 300MB.
Dilbert RSS feed
I agree. This is why I use CMake, CTest and Git.
Test results are stored in a file inside my Git repo, and are therefore part of the "story".
However, what really matters is the total build, regression, bug reporting, electricity consumption, end user satisfaction, employee payroll, and stock price story -- which encompasses more than just revision control and illustrates that "what matters" is a matter of opinion.
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 working on a feature then got interrupted with a high priority bug.
The git-svn bridge also comes in extremely handy, and is a great way to get the benefits of both worlds.
I have to say though, that I think git not handling directories as real objects is a big step backwards. And Subversion's use of metadatas can also be pretty handy sometimes.
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 designed to handle more than a single person modifying the file at a time, concepts like branching, merging etc, don't exist, but for simple single person projects, this is far better than nothing ( and vastly better than manually archiving copies when you remember to)
CVS - Advantage: Supports multiple users, branching and merging (same server, DCVS variant provides some concept of distributed but should be avoided). Relatively easy to setup, and when restricted to ssh only access can be relatively secure. Disadvantage: no distributed support, very coarse security ( if you have access to the server and repository directory you have access, multiple projects on same server are clumsy to secure).
SVN - better than CVS, but harder to setup ( less obvious ?). Distributed support (sort of), but no concept of locking checkouts, so not suitable for code that is not easily merged ( VHDL and Verilog can get ugly when you try to merge what appear to be trivial changes ).
(CVS and SVN are pretty well supported via integration with many IDEs out of the box).
Clearcase - Great big bag of hurt. Avoid this if at all possible. Advantage: Large companies ( Govm't contractors ) use this tool. Ratio of administrators to users 1:10 typically, so expensive manpower. Provides distrubuted (ish) support using Multi-Site. License costs very high. Security is laughable. Any user with network access to the server ports, and an installed licensed client (access to license server) and the ability to assume root on a unix/linux machine can perform any administrative level operations of the files. The client reported username and group membership are trusted by the server to determine access privilege.
Perforce - Despite the authors grouping, P4 provides very good distributed support for controlled development projects. Using proxy servers remote access to files is pretty fast. The only tool listed so far that supports atomic checkins. If any file in the set you are submitting fails to checkin, the whole checkin fails. This may sound like a bad thing if you have never had to fix a problem where one file didn't get checked in, breaking the build. Security (access to parts of the repository) is controlled within the tool, so a fine level of granularity can be achieved. Account management can be done directly in perforce by the admin ( passwords stored locally ), or can be setup to use ldap/kerberos/Active Directory for added trust.
VSS - Small bag of hurt. Small bag because it worked so poorly that we never used it for large projects. Nothing good to say about this, just say no.
Git - I haven't used this enough to know if I like it or not. Having the repository replicated at each remote leaf (user) is nice for the distributed development, but for projects requiring close control of the source code this can be nightmarish. Since every remote site has a copy of the whole history, fixing the problem when Johnny accidentally checks in code from projectX that contractually cannot be shared with projectY can suck.
Spaces not tabs. How can you even pose that question?
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)
That's a lie.
A commit in a non-DVCS is much more than a commit in a DVCS.
With DVCS, they rename the fast, easy part to "commit." The actual merging of your repository with another across a network is one of those items they never discuss, as it is to be performed later. Benchmark a Commit and a Push in a DVCS against a Commit in a non-DVCS, and you'll start gaining my respect as a person who's not fudging the numbers.
Mercurial's SVN re-education page does a good job of describing the advantages.
If only PHB's had a clue, we're forced to use Visual Source Safe at work. I would claim it a legacy system but they just put it in a couple of monthes ago. I think any version control is better than nothing, but I'm not sure Visual Source Safe beats the file system's snap shots that are automatically created.
For the love of god, if you have to use MS software, show the PHB Team Foundation Server. It does a lot more than source control and is superior in every way to VSS. If you have MSDN then it might even be free (beer).
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)?