5 ms·

Git appears to be fast becoming the standard DVCS. Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios: h

Git appears to be fast becoming the standard DVCS. Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios: http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&#... Git has been picking up speed, but Subversion seems to be (nearly) matching its growth. This makes me feel slightly less bad that all my personal projects are checked into Subversion on Dreamhost. :-)

fragsworth 15y ago
To add further evidence toward your argument, consider also the alternative name, "svn": http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2... The popularity would actually be the sum of both.
- whacker 15y ago
  Not necessarily. Some entries might refer to both but be in the same entry. So the correct way to calculate totals would be `subversion + svn - (subersion and svn)`
  - fragsworth 15y ago
    You're right, but in my experience any mention of subversion in a job description tends to only happen once in the document.
  - stephenhalter 15y ago
    The following link should provide the correct unions of job postings: http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+bzr+or+bazaar%2C+darcs%2C+svn+or+subversion%2C+tfs+or+%22team+foundation+server%22&l= http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+...
socratic 15y ago
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.
urschrei 15y ago
I can't speak for anyone else, but I would personally be extremely hesitant about taking a job anywhere that doesn't use a DVCS (and, realistically, for 'DVCS' read: Git or Hg). The technology an organisation uses says a lot about its culture. Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.
- georgieporgie 15y ago
  Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage. In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.
  - benaston 15y ago
    Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space for branches. Creating branches is much quicker due to a fundamentally different way of branching. Finally, it has a killer app in GitHub. What more do you want?
    - georgieporgie 15y ago
      Are you serious? Was that necessary? As I said to billybob, when I work in cvs or Subversion, my team is working on a branch. Personally, I work on a branch of that branch. I check in anytime I like. When I want my teammates to receive my code, I merge back to the team branch. So, I don't really get the 'sandbox' advantage of git. Speed and disk space have never been an issue for me with cvs or Subversion. The content-tracking sounds interesting, but really, I don't rename files all that often. it has a killer app in GitHub That doesn't have any sway on my choice of version control. I sometimes retrieve files from GitHub, but that's about it. I don't know, I haven't heard anything really compelling about git. People who use it seem really excited about it, but not for any reasons that strike me as particularly objective.

fragsworth 15y ago

To add further evidence toward your argument, consider also the alternative name, "svn": http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2... The popularity would actually be the sum of both.

whacker 15y ago
Not necessarily. Some entries might refer to both but be in the same entry. So the correct way to calculate totals would be `subversion + svn - (subersion and svn)`
- fragsworth 15y ago
  You're right, but in my experience any mention of subversion in a job description tends to only happen once in the document.
- stephenhalter 15y ago
  The following link should provide the correct unions of job postings: http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+bzr+or+bazaar%2C+darcs%2C+svn+or+subversion%2C+tfs+or+%22team+foundation+server%22&l= http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+...

socratic 15y ago

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.

urschrei 15y ago

I can't speak for anyone else, but I would personally be extremely hesitant about taking a job anywhere that doesn't use a DVCS (and, realistically, for 'DVCS' read: Git or Hg). The technology an organisation uses says a lot about its culture. Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage.

georgieporgie 15y ago
Anyone who hasn't switched to, or isn't in the process of switching to a DVCS is at a huge disadvantage. In what way? I've dabbled with Git, but I don't see any advantage in it versus Subversion.
- benaston 15y ago
  Are you serious? With a DVCS you can commit to a personal repository offline, this in itself is a killer feature. Git also tracks content rather than files which makes renaming so much less problematic when it comes to subsequent merges (and who likes merges?). Git has the concept of stashing changes enabling rapid context switches without losing work in progress. It is significantly faster. It uses less disk space for branches. Creating branches is much quicker due to a fundamentally different way of branching. Finally, it has a killer app in GitHub. What more do you want?
  - georgieporgie 15y ago
    Are you serious? Was that necessary? As I said to billybob, when I work in cvs or Subversion, my team is working on a branch. Personally, I work on a branch of that branch. I check in anytime I like. When I want my teammates to receive my code, I merge back to the team branch. So, I don't really get the 'sandbox' advantage of git. Speed and disk space have never been an issue for me with cvs or Subversion. The content-tracking sounds interesting, but really, I don't rename files all that often. it has a killer app in GitHub That doesn't have any sway on my choice of version control. I sometimes retrieve files from GitHub, but that's about it. I don't know, I haven't heard anything really compelling about git. People who use it seem really excited about it, but not for any reasons that strike me as particularly objective.