4 ms·

I don't understand our obsession with version control systems. I still find that SVN meets my needs 95% of the time. I've used git for my projects that are host

I don't understand our obsession with version control systems. I still find that SVN meets my needs 95% of the time. I've used git for my projects that are hosted on heroku, but I've never been so impressed with it that I want to completely move to git.

dpritchett 16y ago
How many people are working on your projects? Remember that Linus created git to scratch his own itch in managing patch submissions to the Linux kernel. If you've got squillions of people you don't know working 24/7 around the globe to come up with patches to your C-based system, then git was designed for you. If you're a one- or two-man team who svn merges twice a day, you might not care. Spolsky did a decent job outlining the headaches that DVCS is designed to solve: http://hginit.com/ http://hginit.com/
xbryanx 16y ago
As someone whose duties include branch management and team happiness, moving the DVCS has been a revolution. Improved my job happiness significantly.
patio11 16y ago
So I started using git with my latest project, just to get a feel for what all the Ruby on Rails guys were talking about when they weren't bragging about the size of their Macbooks. The koolaid is delicious. Even in a one-man, one-repo world, I spend a lot less time fighting my VCS for dominance. Example from today: I was working on my deploy branch, where I typically only make to-be-deployed-within-the-hour microchanges. Then I saw another bug, so I squashed it. Commit. Then I saw another bug. So I squashed it. Commit. Then I saw a major opportunity for a simplification with a refactoring. Then I realized the refactoring was under-tested and that failures would be catastrophic, so I started adding extra tests. Now I'm fifteen commits past the last deploy, I have code that I'm 85% positive works on my must-not-fail deploy branch, there is one commit in there which addresses a bug which I want dead, and it is quitting time. I have been in this state in SVN before. Recovery is NOT fun. git branch all-the-work-i-did-today #Creates a new branch whose history looks exactly like deploy's does. git reset --hard production_deploy_92 #Moves head of deploy branch to the tag of the last deploy, essentially forgetting commits afterwards. git cherry-pick carefully_copy_pasted_hash #Nabs the one bug fix that I really wanted to deploy today. Git makes my development and deployment processes better. Transformatively better, in some cases.
- zwieback 16y ago
  Is this common? Usually we have a hard freeze on a release branch a couple of weeks before actually releasing it. I'm working on embedded systems so the test cycles are usually slower due to heavy HW involvement.
  - SwellJoe 16y ago
    In web development, outside of large corporations, I'd say that near-realtime deployment is the norm. Fix the bug, test the bugfix, deploy to servers, all in the same day. git does work well for this. In Open Source projects, as well, folks tend to work directly on HEAD and only go back to old branches/tags for security fixes (if at all). Again, git is tight for this kind of work; which shouldn't be a surprise since it was built for Linux kernel development. Embedded systems have to be damned-near perfect before you ship. Web systems, not so much.
- mberning 16y ago
  I don't think you would have this problem if you were working against a branch rather than the trunk. I feel like it is very simple to merge one file or change from a branch into the trunk and continue working on the branch. Rather more simple than your git solution, but perhaps I am missing something. Do you gain something special by working against the master?
dwc 16y ago
I suspect you are using git the way you use svn. In that case there's little or no benefit. It's essentially the "Blub VCS" problem. Using Git or Mercurial offer a few very powerful things, but they won't seem like much until you have the "Aha!" moment. If you're interested, read the workflow parts of http://progit.org/book/ http://progit.org/book/ and see what you think.
waqf 16y ago
I don't use any language other than Blub, because Blub works just great.
- dpritchett 16y ago
  Thank you for making that connection. Now I have to reread "Beating the Averages" - it's been at least a year since the last read. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- mberning 16y ago
  I think it's quite a stretch to equate a version control system with a general purpose language.
  - waqf 16y ago
    The Blub users are the people who think it's quite a stretch to equate a programming language with a complex and sophisticated tool that can significantly improve or impede your work depending on how well it's designed.
    - mberning 16y ago
      I see. Well I suppose people are just idiots if they can manage to make an uncool and simple piece of software meet their needs. I'm beginning to think that Ellison was right when he compared computing to women's fashion.
pnathan 16y ago
Baaaasically DVCS means you don't need to go through SVN server setup horrors, getting repos becomes sane, and basically your vcs pain goes away. Well, if you use hg. /cheapshot
tghw 16y ago
"Distributed Version Source Control is to centralized source control as source control is to not having source control." * Source: http://www.mokasocial.com/2011/02/four-things-about-fogbugz-and-kiln/ http://www.mokasocial.com/2011/02/four-things-about-fogbugz-...
wnoise 16y ago
So, 5% of the time it doesn't meet your needs. I would find that significant.

dpritchett 16y ago

How many people are working on your projects? Remember that Linus created git to scratch his own itch in managing patch submissions to the Linux kernel. If you've got squillions of people you don't know working 24/7 around the globe to come up with patches to your C-based system, then git was designed for you. If you're a one- or two-man team who svn merges twice a day, you might not care. Spolsky did a decent job outlining the headaches that DVCS is designed to solve: http://hginit.com/ http://hginit.com/

xbryanx 16y ago

As someone whose duties include branch management and team happiness, moving the DVCS has been a revolution. Improved my job happiness significantly.

patio11 16y ago

So I started using git with my latest project, just to get a feel for what all the Ruby on Rails guys were talking about when they weren't bragging about the size of their Macbooks. The koolaid is delicious. Even in a one-man, one-repo world, I spend a lot less time fighting my VCS for dominance. Example from today: I was working on my deploy branch, where I typically only make to-be-deployed-within-the-hour microchanges. Then I saw another bug, so I squashed it. Commit. Then I saw another bug. So I squashed it. Commit. Then I saw a major opportunity for a simplification with a refactoring. Then I realized the refactoring was under-tested and that failures would be catastrophic, so I started adding extra tests. Now I'm fifteen commits past the last deploy, I have code that I'm 85% positive works on my must-not-fail deploy branch, there is one commit in there which addresses a bug which I want dead, and it is quitting time. I have been in this state in SVN before. Recovery is NOT fun. git branch all-the-work-i-did-today #Creates a new branch whose history looks exactly like deploy's does. git reset --hard production_deploy_92 #Moves head of deploy branch to the tag of the last deploy, essentially forgetting commits afterwards. git cherry-pick carefully_copy_pasted_hash #Nabs the one bug fix that I really wanted to deploy today. Git makes my development and deployment processes better. Transformatively better, in some cases.

zwieback 16y ago
Is this common? Usually we have a hard freeze on a release branch a couple of weeks before actually releasing it. I'm working on embedded systems so the test cycles are usually slower due to heavy HW involvement.
- SwellJoe 16y ago
  In web development, outside of large corporations, I'd say that near-realtime deployment is the norm. Fix the bug, test the bugfix, deploy to servers, all in the same day. git does work well for this. In Open Source projects, as well, folks tend to work directly on HEAD and only go back to old branches/tags for security fixes (if at all). Again, git is tight for this kind of work; which shouldn't be a surprise since it was built for Linux kernel development. Embedded systems have to be damned-near perfect before you ship. Web systems, not so much.
mberning 16y ago
I don't think you would have this problem if you were working against a branch rather than the trunk. I feel like it is very simple to merge one file or change from a branch into the trunk and continue working on the branch. Rather more simple than your git solution, but perhaps I am missing something. Do you gain something special by working against the master?

dwc 16y ago

I suspect you are using git the way you use svn. In that case there's little or no benefit. It's essentially the "Blub VCS" problem. Using Git or Mercurial offer a few very powerful things, but they won't seem like much until you have the "Aha!" moment. If you're interested, read the workflow parts of http://progit.org/book/ http://progit.org/book/ and see what you think.

waqf 16y ago

I don't use any language other than Blub, because Blub works just great.

dpritchett 16y ago
Thank you for making that connection. Now I have to reread "Beating the Averages" - it's been at least a year since the last read. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
mberning 16y ago
I think it's quite a stretch to equate a version control system with a general purpose language.
- waqf 16y ago
  The Blub users are the people who think it's quite a stretch to equate a programming language with a complex and sophisticated tool that can significantly improve or impede your work depending on how well it's designed.
  - mberning 16y ago
    I see. Well I suppose people are just idiots if they can manage to make an uncool and simple piece of software meet their needs. I'm beginning to think that Ellison was right when he compared computing to women's fashion.

pnathan 16y ago

Baaaasically DVCS means you don't need to go through SVN server setup horrors, getting repos becomes sane, and basically your vcs pain goes away. Well, if you use hg. /cheapshot

tghw 16y ago

"Distributed Version Source Control is to centralized source control as source control is to not having source control." * Source: http://www.mokasocial.com/2011/02/four-things-about-fogbugz-and-kiln/ http://www.mokasocial.com/2011/02/four-things-about-fogbugz-...

wnoise 16y ago

So, 5% of the time it doesn't meet your needs. I would find that significant.