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."
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.
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?
It's also an advertisement. Sigh.
SCCS predates RCS. Why isn't it on the list?
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.
~500 megahertz K6 laptop w/ ~192K RAM
-single core P4 desktop w/ 512K RAM
I bow before your leet minimalist systems!
Distributed version control systems are only useful for certain types of projects, e.g. a Linux kernel, and useless for others e.g. a three-person development team making an rpc-xml insurance claim submitter.
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.
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?
check out the Mp3 Garbler I built!
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.
I'm stuck using SCCS, you insensitive clod!
Nothing for 6-digit uids?
"If it ain't broken, don't fix it."
Too Many Acronyms
He who knows best knows how little he knows. - Thomas Jefferson
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.
Orwell was an optimist.
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. . . .
Yeah, the article seems to conflate old with bad, and advocates using more complicated technology because its "better", without really considering what "better" is. It's folly to think that distributed version control imposes no overhead, it does. Now whether or not the overhead is worth the features you gain really depends on what your needs are. Open source projects have a MUCH different workflow(tending to involve a large # of globally distributed users, no need to secure code against unauthorized reads etc.) than a lot of small shops which have a small # of developers(and maybe no full-time SCM), tend to be located in the same office etc. The extra overhead of getting a distributed SVN vs. the dead simple SVN setup isn't always worth it.
also leaves out SCCS (a precursor to RCS), as well as layered tools/integration of tools ONTO the SCM (like eclipse -> SVN, etc.)
the article was a good intro to the history of SCM, however i am amazed they didnt just do a box, and put their tool in the upper right hand corner...
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.
Are you able to use any software written in the last decade? Modern desktop applications seems to soak memory like water.
supposed to be using the latest in tech and see themselves as living on the edge of software innovation.
I do. I live on the tail edge:
~500 megahertz K6 laptop w/ ~192K RAM -single core P4 desktop w/ 512K RAM
192K? 512K? Kilobyte? You sure about that? Not Megabyte?
"Ayn Rand is a bloody socialist compared to me." - Robert A. Heinlein
You're so right!!
Brings back memories of (barely) running the first version of Visual C++ on a 386SX.
I'm not a lawyer, but I play one on the Internet. Blog
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>
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.
I wrote parts of this stuff
What? You really can't? You mean EVERY SINGLE ONE of what you want to call a Distributed RCS actually depends on something centralized to make it useful to anyone?
Seriously, you guys need to get over the 'dstributed' bullshit and start realizing that anarchy and decentralization is not actually the solution to ever problem on the planet.
There has to be some point for software to go to start looking for 'distributed' copies.
So many people rant about which RCS to use, and 99% of you don't even know how to fully exploit even the most basic of RCS systems to their advantages.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Ooops...
~500 megahertz K6 laptop w/ ~192[M] RAM
-single core P4 desktop w/ 512[M] RAM
You can tell you're old when you remember when 512K was considered a lot of memory. "I got a Commodore Amiga 500. I could do BASIC or C programming for an entire month and still not fill-up all the space! Wow." ----- Now we have computers with 1000 times that amount and they won't run Win7 or OS X out-of-the-box.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
What matters is the total build and regression story, which encompasses configuration management and revision control--that topic gets far too little attention.
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 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.
I'm not sure that I would blame them...
Ha, my _server_ is a 250MHz MIPS box (Cobalt RaQ2) with 256MB RAM. Pretty sure your systems have MB of ram, not KB of RAM...
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
You can always use a DVCS like a centralized one. The opposite is not true.
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?
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.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
A distributed system is handy because you don't need to be net-connected to do work, so you can take it on your laptop and work on it while on the plane, bus, etc. without worrying about a net connection.
You can pass half-done changes to your coworkers for evaluation without checking them in to the central server.
If doing any work with the linux kernel, git is the most efficient tool to use simply because everyone else is using it.
And of course you can still have a central server to act as the "official" repository. It's just that you can also bypass it when desired.
I cut my source-control eye-teeth writing versioning scripts for sccs based systems.
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.
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.
I am becoming gerund, destroyer of verbs.
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.
We purely use subversion at work (after years of trying to convince them, prior to this all work was done on live server, by multiple devs at once). I've switched to git for most personal projects. Of all the benefits and downsides of git vs svn, I just feel more comfortable in a distributed VCS workflow. My home directory is still subversion though. Seems to address the problem better for wanting to keep my different home directories in sync. Don't want to login to a server and go "oh crap, I forgot to push my changes from other computer".
I've tried converting work to git but it just isn't going to happen. I just snicker when something happens in subversion that I know git can do easier.
(rant)To revert changes in subversion you do a non-intuitive reverse merge? With git it's... git revert. Anytime someone needs to revert a commit in subversion they ask me and I always have to look up the syntax because it doesn't make sense(/rant)
There's nothing mysterious or obscure about CVS. But it might be described as "archaic"
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?
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 - or even just the chapter on Subversion's Delta Editor in the book Beautiful Code.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Tell that to all the idiots who blame Windows XP users for using an OS from 2001.
Spaces not tabs. How can you even pose that question?
What, on the other hand, IS relevant is whether you produce the content with a proper text editor or emacs.
If dcvs seems complex to you, and you don't want to learn how it works, please write up your resignation and quit your job today. Seriously. You'll find far less challenge (and probably better pay) as a bricklayer, and the software industry already has enough people too dumb to learn about their tools. Fuck, your statement is like a builder saying "at my last house building jobs one of the guys tried to convert me from using a hammer to using a nail gun, telling me how much effort it could save me and then proceeded to show me how to put nails in it and that it needed plugging in. Seems like complete overkill to me"
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)
Fraud Alert: This Slashdot story was written to make a new commercial version control system, Plastic, seem as though it is the best, in my opinion.
Was a Slashdot editor paid to run this story? Is it Slashdot company policy to allow sneaky advertising???
You can judge a company's products by its morals: Oracle, Microsoft (huge hassles with products being unfinished), AOL (misleading accounting), and Enron (misleading accounting) are examples that come to mind.
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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Clearly the words of a kid with no clue.
Software companies, pulling in real money, not startups doomed to fail like the dotcom before them, don't need to introduce new tools into their workflow just for shits and giggles.
When you introduce third-party services, you are introducing the possibility of failure into your system.
If a tool solves no problem (in business, that means "show me the money") but introduces cost (in business, that means "training, ops, maintenance, existing bureaucracy, the list goes on ...") then it's asinine.
Not every project modelled after the Linux kernel.
I sure envy you kids using your shiny new BeOS systems.
Here I am stuck using the ole Unix and Unix-like systems that I've been using since 1982.
I'd like to take this opportunity to push my very own brand new project for a VCS for large binary files. Most VCS:s so far has been developed for code. Nothing wrong with that, but there are many other kinds of data that also deserves a safe, version controlled repository they can call home. My tool is named "boar", it's written in python and I need users and help to make it perfect.
To quote the project page: "Boar aims to be the perfect way to make sure your most important digital information, like pictures, movies and documents, are stored safely. If you are familiar with vcs software such as Subversion, you might think of boar as "version control for large binary files". But keep reading, because there is more to it..."
Check it out! (pun intended)
http://code.google.com/p/boar/
It doesn't do a crappy job of branching and merging. It's the best tool I've ever used for branching and merging. I don't know what the hell they're talking about.
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 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.
Wolde you bothe eate your cake, and have your cake?
Plastic SCM [...] Plastic’s developers (BTW, I’m one of them) [...] A Community Edition of Plastic SCM was launched in November 2010.
There you go, that's what this article is ultimately about - getting the word out on that. ;) It's a slashvertisement, but it's a good/interesting one, so personally, I'm not complaining.
yeah, that's the way to spin it gramps, awkwardly try to cover up your bout of CRS while ranting about how these damn kids don't appreciate the luxury they wallow in, and how did they get on your lawn... For an encore, you can complain about the ebbil gubbemint wanting to force you to pay for other people's hospital expenses, and they better keep their mitts off your medicare...
When you introduce third-party services, you are introducing the possibility of failure into your system.
SVN/CVS _is_ a third party service you moronic dipshit. anything not running on my development machine is a third party service. it doesnt matter if the guy on the next desk over is maintaining the svn server, if it goes down it disrupts my work. if the internet goes down it disrupts my work. if I'm away from the office and without 3g reception it disrupts my work. none of this is an issue with DVCS.
you're just another old man who hasnt kept up with technology and should have retired a long time ago. "computers?!! clearly the tools of a kid with no clue. flat files are good enough, computers are just fancy tools people use for shits and giggles"
Personally, I thought it was complete overkill for the two-man project we were working on.
With git, setting up a new project is
cd myproj
git init .
git add .
git commit -m "initial commit"
and you're off--no setting up a server. And if you want to share it with one or two people, ssh will do.
I suspect bzr is similar.
So at least for me the low-overhead setup makes them more attractive for small projects too.
I'll admit they require some initial investment to learn, but it's very much worth it.
Our legacy system was a "hey only one person can write files to this directory but you can copy the files to this directory for developmenstuction" setup. When I mentioned source control I was looked at like I was the new kid telling them what to do because they had no problems with their current system (in their minds). Rough stuff.
I've always heard of git as a distributed version control system, and as such I've been ignoring it. Ie, all my coworkers are in the office usually, not distantly separated and loosely connected kernel devs. Examples I've seen of where people love git tend to be nearly exclusively open source projects composed of distributed developers.
So where does having a local repository (and the huge space this entails) actually help the person who's sitting in a cube with a fast lan to the server? Almost never have I wanted to have an entire repository local, having 3 or 4 branches is great, and then only a subset of the full directory tree, and very rarely I'll do a diff against an archaic branch (and I can afford the 1 second wait that takes).
So what does it do for a corporate user that SVN does not do? For background, I'm still with CVS at work, and we're debating about migrating to either SVN or Perforce (I like perforce, and it's what the rest of the company uses, but one person has vetoed it for some reason). I know why Linus hates it, and his reasons are correct for his uses but it's not necessarily true for all.
I love change sets; I often have multiple ongoing tasks in the same source directory, or the same task that I want to split into multiple commits. CVS has zero support for this. Perforce has full support. SVN lets me group into change-lists, but none of this is remembered at the back end from what I can see. Git has this at the back end so you can do things like cherry pick, but you can't group your working files into different sets and then say "commit this set only". So for me neither is better than Perforce for work flow. But that's just me; I'm certain other people see the distributed stuff as the must-have feature.
FOR YOU.
I think CVS is better, since I don't have to deal with the big-freaking URLs all of the time. I wish they truly had made a (much-closer-to) superset of CVS. Doing integration with CVS is much easier than with subversion, since I can bump the version and do the tag right BEFORE I submit it, not at the beginning of the integration process.. so I have to do everything basically 'backwards' in subversion.
Before OS X, Macs had a bit of trouble with version control. No command-line, see. In fact, I only knew of two that were reasonably-priced or free: MacCVS and Voodoo. I never got a chance to use Voodoo, but its approach and feature-set looked cool. Can anyone comment on how well it worked? Or what version-control system you used on classic Macs?
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
Actually ENVY Developer was waaay more sophisticated than any of the tools presented here. Back in the early 90s you could have distributed development, anybody could make their own branches of the code, and you could pick and choose what version of each class you wanted to build with. Also it eschewed flat files and instead used a more powerful transactional database store.
The article clearly has a bias to text-only solutions.
Thinker: v. to tinker while cogitating.
I like it! And I'll use it. (If refudiate is good enough for OED, thinker's great, too.)
I'm not a lawyer, but I play one on the Internet. Blog
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)?
SVN/CVS is a a third party service that works, integrated into the workflow long ago. DCVS is a completely different workflow with a steep learning curve and the tangible benefits are questionable for some organizations.
Some people, you know, instead of obsessing with their tools, write code.
But don't let anyone interrupt your work, your fiefdom is appreciated.
Terrible analogy. People write code with text editors and IDEs, not SCMs.
It's more like the difference between QWERTY and DVORAK keyboards. One is clearly better, but people familiar with QWERTY do just fine.
I love change sets; I often have multiple ongoing tasks in the same source directory, or the same task that I want to split into multiple commits. CVS has zero support for this. Perforce has full support. SVN lets me group into change-lists, but none of this is remembered at the back end from what I can see. Git has this at the back end so you can do things like cherry pick, but you can't group your working files into different sets and then say "commit this set only".
Actually, yes you can. Selecting which files to commit is actually even part of the normal workflow.
-rozzin.
I've always heard of git as a distributed version control system, and as such I've been ignoring it. Ie, all my coworkers are in the office usually, not distantly separated and loosely connected kernel devs. Examples I've seen of where people love git tend to be nearly exclusively open source projects composed of distributed developers.
So where does having a local repository (and the huge space this entails) actually help the person who's sitting in a cube with a fast lan to the server?
If you actually compare the stats for space used by different systems, you'll find that, between all of the different DVCS tools (Git, Bazaar, Mercurial, etc.) and Subversion,
Subversion checkouts actually tend to use the most space: yes, a Subversion checkout without a local repository--which means that it only gives you immediate access to one version, and doesn't allow you to do annotations or anything else without round-tripping through the server--actually tends to use more space than a local DVCS repository that stores all of the history and allows you to batch and group commits, do fast annotates, deal with merge-conflicts more easily, be immune to server/network reliability issues, etc.
Try a comparison--do a svn checkout of some project, then import the project into the DVCS of your choice and compare the space used by each. I usually use Bazaar with bzr-svn for this, with "bzr branch " to import just the trunk, or with "bzr svn-import " to import all of the branches. Bazaar is the DVCS that everyone wails on for `using more space than Git', so I was initially hesitant to use it; but then I realised that it still uses only half as much space as a checkout from Subversion.
-rozzin.
>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?
If this is your work environment, quite little. In practise, one of these things tends to happen: need to work *not* in the same office, team size increases (server load increases), server goes down. In all of them, the fast server isn't so fast anymore.
>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)?
The push can be automated if you want. But usually you don't necessarily want that (and having the possibility is an advantage).
True, but selecting the files is a manual process. You can't just say something like "git commit bugfix-23" as far as I know.
Sometimes you want to do some experimental work that is complicated enough to be version-controlled, but not stable enough for other developers to see yet.
In SVN you have to use a branch, and SVN branches are not that convenient to use. Otherwise, when another developer checks out the tree or commits his own changes, he will see the unstable changes you have committed.
In Git you can simply commit your experimental changes and push them (or let others pull them) when they are ready.
And if you frequently want to push immediately after commit, just make such a shortcut.
Okay, no flames in my direction. I remember Source Safe by One Tree Software before the MicroNuts borked it beyond belief. Once Microsoft got their claws into it, there was little left of what I remember. The original developers of SS were focused on usability and quickly added features when we ran into issues. I miss my old SS.
Plastic does a good job here because it can work in centralized mode and still with much better branching and merging than the non-DVCS.