An Illustrated Version Control Timeline 244
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 (Score:5, Insightful)
Arcane CVS and what not (Score:3, Insightful)
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?
Meh. (Score:3, Insightful)
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.
Source control is so political (Score:5, Insightful)
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:My god, it's full of troll. (Score:2, Insightful)
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.
Re:pardon, your ignorance is showing (Score:1, Insightful)
It's extremely useful even for a single developer.
You can still use DVCS systems as if they were centralized, without any inconvenience.
I'm not even going to bother to list them myself, as wikipedia does a fine job already.
http://en.wikipedia.org/wiki/Distributed_revision_control [wikipedia.org]
Every single project I've worked that didn't use DVCS, I missed it alot. DVCS is how it should be done, and CVCS is inherently flawed.
However, I also think the article sucked.
Re:Advertising disguised as history lesson. (Score:4, Insightful)
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...
Re:Advertising disguised as history lesson. (Score:3, Insightful)
Linus Torvalds sometimes shoots his mouth off for no good reason, and he tends to look at everything in terms of how it would work for the Linux kernel.
The fact is that CVS would be bad for the Linux kernel development process, which really does need a distributed VCS. You can kinda sorta make something like that work on CVS, but you'd wind up with a nightmare, and if you wanted to spend the time to write everything you'd need to make it work you might as well write something like Git instead.
CVS is perfectly usable as a centralized system, despite its deficiencies, and it's no more arcane than Subversion.
Re:CVS May be Old, but... (Score:5, Insightful)
"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 (Score:5, Insightful)
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 (Score:4, Insightful)
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:Advertising disguised as history lesson. (Score:3, Insightful)
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 also currently use SCCS to revision system data files on a Solaris project because it comes with the OS out of the box -- cannot install something else -- and it works just fine.
Bottom line: If I ever need to use something else, I'll learn it, but here and casually at home, I already know RCS/CVS and they work just fine.
Re:pardon, your ignorance is showing (Score:3, Insightful)
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.
Horses for Courses (Score:2, Insightful)
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.
Re:Subversion branching and merging (Score:4, Insightful)
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:My god, it's full of troll. (Score:2, Insightful)
- 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 for end-users to wrap their heads around it. Merging works, is undergoing constant improvement, but may not be suitable to all styles of development.
For our particular shop, SVN simply works. Couple that with being able to use FSVS to version-control our servers (mostly for tracking changes to the file system), and I'm happy enough that it's not worth moving. (Considering our prior SCM was SourceSafe on top of VSS, nearly any SCM was a better choice. SVN was the natural upgrade path back in the 2004-2006 timeframe. They were there, the tools were ready, and it played nicely with our environment.)
If we needed decentralized repositories, then we'd go look at git, Mercurial or one of the others.
At the end of the day, it's more important that you use at least some sort of SCM, rather then which SCM you use.
Re:pardon, your ignorance is showing (Score:3, Insightful)
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.
Re:My god, it's full of troll. (Score:4, Insightful)
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)?