5 ms·

You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be: http://www.indeed.com/jobtrends?q=git%2C+hg%2

You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be: http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+bzr%2C+darcs http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+... Obviously, cvs and svn will be with us for some time still, but those are not distributed version control systems (DVCS). However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?

j_col 15y ago
> However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever? Well, I guess I must be one of those low quality developers, as I have yet to hear/read a compelling argument that would motivate me not to use SVN. I have always considered the source control problem to be solved: distributed version control attempts to solve a problem that I don't have, and never had while working on major projects with distributed teams in the past.
billybob 15y ago
"is distributed version control so much better than centralized version control that we will all eventually be using a DVCS?" I can't predict the future, but I do think DVCS is fundamentally superior. Joel Spolsky called it "possibly the biggest advance in software development technology in the ten years I’ve been writing articles here." (http://www.joelonsoftware.com/items/2010/03/17.html http://www.joelonsoftware.com/items/2010/03/17.html) Let me describe a key weakness of centralized version control and how decentralizing fixes it. Say you're working on a project with others. All of you commit to the repo, and you use it to deploy to production. When you're coding experimentally, you have to make a choice: do I commit often, possibly giving half-baked code to my peers? Or do I commit only when I'm totally done, with long periods between commits, during which I can't roll back changes? DVCS eliminates this painful choice. Commit as often as you like on your local repo. When your code is ready, push up to the shared repo. If you like, you can even do better: push up to a shared development branch for review and merging into the deployable branch. And better than that: if it took you 20 false steps to get to the end result, doing stuff, undoing it, redoing it differently, etc, you can clean up that commit history to a single, logical, readable commit for your teammates to read. That is fundamentally better for teammwork. Add all the stuff about offline access, etc, and it's just clearly better.
- georgieporgie 15y ago
  DVCS eliminates this painful choice. Commit as often as you like on your local repo I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox. I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch. How is my process any different than using Git?
  - wnight 15y ago
    Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc. Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete. Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc. And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie. tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.
    - georgieporgie 15y ago
      In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness Huh? Branching code in no way affects the code that has been branched. Instead of a flat directory as your sandbox you've got a full VCS at your disposal I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem. So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.

j_col 15y ago

> However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever? Well, I guess I must be one of those low quality developers, as I have yet to hear/read a compelling argument that would motivate me not to use SVN. I have always considered the source control problem to be solved: distributed version control attempts to solve a problem that I don't have, and never had while working on major projects with distributed teams in the past.

billybob 15y ago

"is distributed version control so much better than centralized version control that we will all eventually be using a DVCS?" I can't predict the future, but I do think DVCS is fundamentally superior. Joel Spolsky called it "possibly the biggest advance in software development technology in the ten years I’ve been writing articles here." (http://www.joelonsoftware.com/items/2010/03/17.html http://www.joelonsoftware.com/items/2010/03/17.html) Let me describe a key weakness of centralized version control and how decentralizing fixes it. Say you're working on a project with others. All of you commit to the repo, and you use it to deploy to production. When you're coding experimentally, you have to make a choice: do I commit often, possibly giving half-baked code to my peers? Or do I commit only when I'm totally done, with long periods between commits, during which I can't roll back changes? DVCS eliminates this painful choice. Commit as often as you like on your local repo. When your code is ready, push up to the shared repo. If you like, you can even do better: push up to a shared development branch for review and merging into the deployable branch. And better than that: if it took you 20 false steps to get to the end result, doing stuff, undoing it, redoing it differently, etc, you can clean up that commit history to a single, logical, readable commit for your teammates to read. That is fundamentally better for teammwork. Add all the stuff about offline access, etc, and it's just clearly better.

georgieporgie 15y ago
DVCS eliminates this painful choice. Commit as often as you like on your local repo I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox. I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch. How is my process any different than using Git?
- wnight 15y ago
  Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc. Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete. Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc. And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie. tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.
  - georgieporgie 15y ago
    In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness Huh? Branching code in no way affects the code that has been branched. Instead of a flat directory as your sandbox you've got a full VCS at your disposal I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem. So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.