4 ms·

Note: Overrated means something is widely regarded as good ... but isn't. A version control system should be very simple, hardly noticeable like the original

Note: Overrated means something is widely regarded as good ... but isn't. A version control system should be very simple, hardly noticeable like the original RCS. 1. checkin the current version after each change. 2. if a serious problem is encountered, checkout an earlier version to see what happened and find when and where bug was introduced. That is about it and RCS does it with a handful of commands. The obvious question is why can't a distributed version control system like Git hide most of the complexity of managing a network of distributed repositories from the developer, at most adding a few network commands, e.g. clone, pull, push? Where do the 148 commands come from? Why not just use the standard RCS command line interface with a small number of additions and let the back end deal with the distributed repositories? Extend the RCS/CVS/SVN sequential ids with a suffix to identify something like repository/branch to keep track of local changes? Sincerely, Bit by Git

brandonbloom 12y ago
A version control system should be [...] hardly noticeable And that right there is the fundamental philosophical difference which is preventing you from understanding why people like Git. It's not just a revision control system, it's a tool for crafting code and patches. Git is a fundamental part of my workflow for how I write code locally, even without contributors, and beyond backup/undo use-cases. However, with contributors, patches count as communication, and tools to help me craft those patches effectively were missing from my toolbox prior to Git.
- NumberSix 12y ago
  I think I have a good understanding of why people like Git. I question whether they should. In my experience, the time to learn Git for people unfamiliar with it is significantly larger than for any RCS-style version control system including Subversion which is probably the most complicated RCS-style version control system. Similarly, even if you are proficient with Git, on average it takes significantly longer to use Git to do the same things as an RCS style version control system. This is true even if you use Git in a very simple way. If you use it in one of the very complex ways like the Android project/Git/Gerrit/Jenkins morass, it will take a lot longer. This time is a real cost to a business or an open-source project or what have you. Simplicity is often faster, cheaper, and better. I argue that it is more effective in a team project to share the actual history of the development in a shared development branch -- warts and all. Production and release candidates -- the works of art that you are trying to create -- can be tagged or identified in some other way. Bit by Git
  - eropple 12y ago
    Oh c'mon, this is handwavy no-true-Scotsman bullshit. Anybody who says you're wrong, that they're faster, will be referred back to your unsourced claim of "on average". As for me: I administered and supported SVN at a shop with about a hundred and twenty developers and about half a million commits and an overall trunk size in the gigabytes. I've spent time in the SVN codebase and am comfortable saying I understand it and can wield it better than most people who aren't committers. And guess what? I'm significantly faster at using Git for pretty much anything I've ever had occasion to do with it, while being able to leverage the conceptually-very-simple plumbing architecture of Git to do things that make other developers a lot faster. (Git isn't perfect. Mercurial is better. But the answer isn't regression to a poorer model.)

brandonbloom 12y ago

A version control system should be [...] hardly noticeable And that right there is the fundamental philosophical difference which is preventing you from understanding why people like Git. It's not just a revision control system, it's a tool for crafting code and patches. Git is a fundamental part of my workflow for how I write code locally, even without contributors, and beyond backup/undo use-cases. However, with contributors, patches count as communication, and tools to help me craft those patches effectively were missing from my toolbox prior to Git.

NumberSix 12y ago
I think I have a good understanding of why people like Git. I question whether they should. In my experience, the time to learn Git for people unfamiliar with it is significantly larger than for any RCS-style version control system including Subversion which is probably the most complicated RCS-style version control system. Similarly, even if you are proficient with Git, on average it takes significantly longer to use Git to do the same things as an RCS style version control system. This is true even if you use Git in a very simple way. If you use it in one of the very complex ways like the Android project/Git/Gerrit/Jenkins morass, it will take a lot longer. This time is a real cost to a business or an open-source project or what have you. Simplicity is often faster, cheaper, and better. I argue that it is more effective in a team project to share the actual history of the development in a shared development branch -- warts and all. Production and release candidates -- the works of art that you are trying to create -- can be tagged or identified in some other way. Bit by Git
- eropple 12y ago
  Oh c'mon, this is handwavy no-true-Scotsman bullshit. Anybody who says you're wrong, that they're faster, will be referred back to your unsourced claim of "on average". As for me: I administered and supported SVN at a shop with about a hundred and twenty developers and about half a million commits and an overall trunk size in the gigabytes. I've spent time in the SVN codebase and am comfortable saying I understand it and can wield it better than most people who aren't committers. And guess what? I'm significantly faster at using Git for pretty much anything I've ever had occasion to do with it, while being able to leverage the conceptually-very-simple plumbing architecture of Git to do things that make other developers a lot faster. (Git isn't perfect. Mercurial is better. But the answer isn't regression to a poorer model.)