6 ms·

Jesus christ. The amount of time people spend blogging about how great git is could be surely put to better use. It's just a linkbait headline. Use whatever fi

by axod 17y ago

Jesus christ. The amount of time people spend blogging about how great git is could be surely put to better use. It's just a linkbait headline. Use whatever fits your usecase the best. For me to switch from svn to git, I need to be experiencing pain using svn. I don't feel any pain :/ Of course if I'm working on a project in the future that looks like git may help, I'll look at git and see if it'd be more appropriate than svn... Wish people would quit with the "Tool X is always better than Tool Y".

leftnode 17y ago
I'm not sure why you were downmodded, but I upmodded you because I agree. I use subversion daily, and I love it. I've dabbled in git, I understand the strengths, but for me, its not worth spending the time to migrate all of my projects over there.
- RyanMcGreal 17y ago
  http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ http://www.simplisticcomplexity.com/2008/03/05/cleanly-migra...
FooBarWidget 17y ago
I didn't experience pain either... until I used git for a while. Then I realized all the pain that I was suffering but wasn't aware of. > The amount of time people spend blogging about how great git is could be surely put to better use. Maybe they're spending so much time blogging because git really is that good?
- axod 17y ago
  How can you not be aware of pain? If I was wasting time on a laborious task, I think I'd know about it and think of a better way. Care to share an example from your experience? During my average day, I probably spend a few minutes total messing with svn. For my usecase, it's already optimum. The only way I could reduce that time is to not put in any commit messages :/
  - timwiseman 17y ago
    How can you not be aware of pain? Anecdotally, this is fairly common. I have known people that did not realize they had fairly bad back pain until they went to the doctor for something else and had it treated. Sometimes, it is only in absence of something that we really notice it, especially if it is truly chronic. I suspect most people have gone somewhere with a fairly loud background noise. At first they may notice it, but after being there for a while they may forget about it and may even forget it was ever there. But they will notice and realize how annoying it was if that noise ever stops.
    - axod 17y ago
      I don't think the analogy holds here though. I type 'svn commit' 'svn update', it works. quickly. For me, it's like suggesting I change from using 'cd' to change directory, to using 'awesome-cd' to change directory :/
      - timwiseman 17y ago
        I have never used SVN or Git (I use Hg at home and VSS at work), so I can't say there. What I can say is that I didn't realize how painful Java was for me until I started learning Python. That may be a closer analogy, though still not perfect.
      - pmichaud 17y ago
        Why would I switch from horses to these new-fangled automatic carriages? Horses get me where I need to go.
  - steveklabnik 17y ago
    When your server's drive crashes, and you lose all of your history... you'll feel some pain. Backups help, but not as good as git does. See what happened with _why? He nuked everything, but none of it really went away. With CVCS, the community would have lost everything.
  - warp 17y ago
    Here is an example from my experience: Sometimes when I'm developing, and ready to commit something I notice I've made a few unrelated changes/bugfixes. I could just commit the whole thing at once, but that makes merging a hassle because I probably want to merge those bugfixes to trunk much sooner than any code which implements a new feature. So, I would need some way to commit only certain diff chunks from each file. I understand from "http://www.gitcasts.com/posts/interactive-adding http://www.gitcasts.com/posts/interactive-adding that git can do that. So far it hasn't been incentive enough to switch, but it's one example of the pain of subversion.
- durin42 17y ago
  > Maybe they're spending so much time blogging because git really is that good? That may be, but they're the only community I see being extremely in-your-face about their tool and how it's clearly beating the pants off everything else. Personally, I'd be more interested why they feel the need to declare its goodness so loudly, when if it really is as awesome as these articles make it sound then it'll spread like wildfire by word of mouth. emacs changed the way I write code, and made me wildly efficient compared to before I used it. That doesn't mean I'm going to go and start browbeating people into using it. The git community seems to be blind to the notion that git (as wonderful as it is) might not be for everyone.
  - snprbob86 17y ago
    All these people shouting about it are are spreading it by word of mouth and it has spread like wildfire. Maybe it is time to consider if it really is that good?
  - FooBarWidget 17y ago
    How is an article on someone elses website "in-your-face"? Nobody's pointing a gun at you and forcing you to read it. If blogging about it is "in-your-face" then what do you consider an acceptable method to tell others about a great tool?
- ebishop 17y ago
  While I can understand how git is better for the majority of use-cases, I found that it was far less suitable than SVN for what I want to do. I used git for a while (3-6 months) and then switched BACK to using SVN. It's true I didn't experience pain until I started using git. That's when the pain started. First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic. Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus. For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers.
  - joeyh 17y ago
    If adding a shell script to your development environment results in pain every time you need to set it up, that says you haven't automated setting up the environment. One great way to automate it is to put all such scripts (surely this would not be the only one?) and other files in a version controlled repository; then you just have one more thing to check out. (If checking out one more thing results in pain, you should think about automating the checkout too... This line of thinking has resulted in me keeping everything in git and using a single `mr` command (google will find it) to check out all my respositories when I'm setting up a new account.) Revision numbers are not impossible with DVCS; bzr has repo-local revision numbers. But once a number becomes longer than 3 digits, I cut and paste it anyway; if I'm already pasting, the longer size of git's sha1s doesn't matter.
oscardelben 17y ago
The article is indeed for people who are pretty satisfied with svn. I don't think of the article as a waste of time because there are many people who don't know what are the advantages of git over svn.
RyanMcGreal 17y ago
To borrow a concept from programming languages, svn is blub.
- axod 17y ago
  That's about as good an argument as saying only communists use svn. So basically your argument is that the only people who can have a valid opinion about the usefulness of different rcs's are those using git :/
  - dasil003 17y ago
    I agreed with the first two sentences of your original post. People waste entirely too much time writing about git vs svn. However, you are absolutely wrong here. The blub argument is not that you must use git to have a valid opinion about git. It is that you must grok the power of the features. You could have a reasonable background of modern version control by using Mercurial, DARCS, BitKeeper, etc, even if it didn't inform you perfectly about what git can do (rebase -i anyone?). However if you've only used SVN or CVS then you are completely in the dark. I'm sorry but it's the indisputable truth. It's like someone who's never programmed in anything but Java, explaining how LISP macros are of no use to them. As if they would even know what a macro could do for them.
    - axod 17y ago
      ... and I'm absolutely aware of what git can do. I'm not making an uninformed choice here, I know the fun things git can do, and I'm sure if I switched to git, I'd probably spend all day playing with its awesome features, then I'd probably write a blog post proclaiming how awesome it is. Or, I could just continue using svn which perfectly fits my use case and does everything I need it to do. As I say, it stays out of my way and doesn't take any of my time up. You seem to assume everyone uses revision control in exactly the same way and that everyone has exactly the same needs/pain points/etc
      - dasil003 17y ago
compay 17y ago
I'm also surprised people are still arguing about this. I switched to Git so long ago I sometimes need to look at the man pages for SVN when I use it because I've forgotten how to do some things. IMHO unless you have a good reason to use SVN, you really should be using some kind of DVCS. SVN compared to Git/Mercurial/etc is like nano compared vim or emacs. I do definitely consider "I'm already using SVN and I'm happy" to be a completely valid reason to use SVN because people should be free to use what they like. But if that is your line of thought, keep in mind that you are making a concious decision to continue with a much less powerful tool and are not taking advantage of something that, if you put the time into learning it, would benefit you.
- axod 17y ago
  Still generalizing IMHO. Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs. Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.
  - zaphar 17y ago
    Name a use case where svn is more suited than git is. I for one can't think of a single one. At most they might be equivalent. More likely git will be one of: * faster * more featureful I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
    - sid0 17y ago
      When you want to lock binary files as "being edited". DVCSes by design cannot lock files. edit: I'd also say that SVN integrates better with a lot of things than git/hg do.
    - axod 17y ago
      One off the top of my head: From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.
mechanical_fish 17y ago
I don't feel any pain. Have you asked your colleagues if your use of svn is causing them pain? Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said. But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later. So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools? P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.
- doty 17y ago
  How does git make programmer A want to disentangle the fix? How does git keep Programmer B from making changes against the wrong base? (Admittedly, git may make it easier to move that fix from the wrong base to the right one, but it doesn't make it harder to make the mistake; if anything, a prolifiration of branches an independent lines of development makes it easier to make that mistake, not harder.) How does git make merging easier? Doesn't it do a traditional three-way merge, just like svn? And it seems like in DVCS you have more merging, not less...
  - 17y ago
steveklabnik 17y ago
> Wish people would quit with the "Tool X is always better than Tool Y". Most of the time, I would agree with you. In this case, DVCS is a superset of VCS, so it is _always_ better.
- sid0 17y ago
  Centralized VCSes can lock files. DVCSes cannot. Ergo, DVCSes are not a superset of centralized VCSes.
  - steveklabnik 17y ago
    Couldn't the upstream repository just not accept changes to that file? I'm sure this could just be managed by some kind of commit hook.
    - sid0 17y ago
      Interesting. I hadn't considered that possibility. I'm more familiar with hg than with git, but from what I gathered in #mercurial, it should be possible to write a combined extension + a commit hook that: * allows people with appropriate permissions to lock and unlock files * sets locked files to read-only on pull from the canonical repository, so that users are warned beforehand that the files are locked * rejects commits that modify locked files except for by the person that holds the key There are a bunch of issues that need to be worked out, but I think the problem is tractable. Nice, thanks for the idea!
- doty 17y ago
  A superset is not always better. Consider domain-specific languages vs. general-purpose languages. You need to weigh the benefits of increased power with the drawbacks of additional complexity.
  - steveklabnik 17y ago
    Ease of use is important, we certainly agree on that. But "git clone url" vs "svn co url" and "git commit -a" vs "svn commit" isn't significantly more complex.
DanielBMarkham 17y ago
Hear hear! Versioning is about 1/10th of software engineering, and it's about 1/1000th of running a successful startup. I wonder how many companies managed to survive in the bad old dark ages before we had git? </sarcasm> This incessant cheerleading is obnoxious. Source control is simply not that much of a time sink (or shouldn't be) to warrant all this attention. Work on making something people want, folks. Stop getting all wrapped up around the axle about some nifty new wizzbang tool.
uuilly 17y ago
I just moved from a 4 man svn project to a 4 man git project. It took me a month before I didn't feel like an ass in git. I'm still not sure what I have gained. I know git is so powerful and does so many things, but I'm a simple user. To me version control is like a doormat: I pass it really quickly on the way into the house. If that's what it is to you git will not open up a new world. In fact it will just take you longer to become proficient and waste time that could otherwise be spent coding.
- jerf 17y ago
  When you say you are a "user", are you not a programmer? If so, then you probably won't see much to be excited about. If you are a programmer and you aren't seeing how source control helps you (and it sounds like you weren't seeing any particular benefit with SVN either), then you either don't have much experience, or are dangerously close to being the type of programmer who repeats the same year ten times, rather than acquiring ten years of experience. You really need to work on internalizing what source control allows you to do, git, svn, or otherwise. Not knowing what source control is good for is like a furniture maker wondering what a lathe is good for, beyond turning a simple cylinder. (Among other things, if there was a Furniture News, that's not the sort of comment that ought to be getting upvotes...) Edit: Yes, nothing scores downmods like telling people that you need to know things to be a good developer. Guess what? You need to know things to be a good developer. Knowing what source control is and how to use it effectively is one of them. Downmodding me won't make that go away, nor will it magically make people who don't "get" source control better developers.
  - uuilly 17y ago
    jerf, using the analogy of the furniture builder: -Your shop would be your OS. -Your wood would be your programming language. -Your lathe would be your IDE / text editor -Your broom would be your source control system. A furniture builder would use a broom to reset after a messy job and at the end of the day. That is about how I use source control. I've never worked on a huge open source project with lots of branching and merging. I've worked in small teams where we have one evolving version and that's all we really care about. SVN works fine for syncing and resolving conflicts. If SVN is a broom, Git is a complicated vacuum cleaner. Perhaps more powerful, but when I started using it, I took me 10x longer to clean the floor. I learned CVS, Rational Clearcase, MS Source Safe and SVN on the first day and spent very little time thinking about them afterwards. While I liked SVN the best, they all did their job well enough. I'm now good enough at git that it's not a time sink, but I'm not sure what I really gained from it. Furthermore, you may want to adjust your tone and try not to jump to conclusions. You probably can't intuit what kind of a person / developer I am from a single comment.

by axod 17y ago

leftnode 17y ago

I'm not sure why you were downmodded, but I upmodded you because I agree. I use subversion daily, and I love it. I've dabbled in git, I understand the strengths, but for me, its not worth spending the time to migrate all of my projects over there.

RyanMcGreal 17y ago
http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ http://www.simplisticcomplexity.com/2008/03/05/cleanly-migra...

FooBarWidget 17y ago

I didn't experience pain either... until I used git for a while. Then I realized all the pain that I was suffering but wasn't aware of. > The amount of time people spend blogging about how great git is could be surely put to better use. Maybe they're spending so much time blogging because git really is that good?

axod 17y ago
How can you not be aware of pain? If I was wasting time on a laborious task, I think I'd know about it and think of a better way. Care to share an example from your experience? During my average day, I probably spend a few minutes total messing with svn. For my usecase, it's already optimum. The only way I could reduce that time is to not put in any commit messages :/
- timwiseman 17y ago
  How can you not be aware of pain? Anecdotally, this is fairly common. I have known people that did not realize they had fairly bad back pain until they went to the doctor for something else and had it treated. Sometimes, it is only in absence of something that we really notice it, especially if it is truly chronic. I suspect most people have gone somewhere with a fairly loud background noise. At first they may notice it, but after being there for a while they may forget about it and may even forget it was ever there. But they will notice and realize how annoying it was if that noise ever stops.
  - axod 17y ago
    I don't think the analogy holds here though. I type 'svn commit' 'svn update', it works. quickly. For me, it's like suggesting I change from using 'cd' to change directory, to using 'awesome-cd' to change directory :/
    - timwiseman 17y ago
      I have never used SVN or Git (I use Hg at home and VSS at work), so I can't say there. What I can say is that I didn't realize how painful Java was for me until I started learning Python. That may be a closer analogy, though still not perfect.
    - pmichaud 17y ago
      Why would I switch from horses to these new-fangled automatic carriages? Horses get me where I need to go.
- steveklabnik 17y ago
  When your server's drive crashes, and you lose all of your history... you'll feel some pain. Backups help, but not as good as git does. See what happened with _why? He nuked everything, but none of it really went away. With CVCS, the community would have lost everything.
- warp 17y ago
  Here is an example from my experience: Sometimes when I'm developing, and ready to commit something I notice I've made a few unrelated changes/bugfixes. I could just commit the whole thing at once, but that makes merging a hassle because I probably want to merge those bugfixes to trunk much sooner than any code which implements a new feature. So, I would need some way to commit only certain diff chunks from each file. I understand from "http://www.gitcasts.com/posts/interactive-adding http://www.gitcasts.com/posts/interactive-adding that git can do that. So far it hasn't been incentive enough to switch, but it's one example of the pain of subversion.
durin42 17y ago
> Maybe they're spending so much time blogging because git really is that good? That may be, but they're the only community I see being extremely in-your-face about their tool and how it's clearly beating the pants off everything else. Personally, I'd be more interested why they feel the need to declare its goodness so loudly, when if it really is as awesome as these articles make it sound then it'll spread like wildfire by word of mouth. emacs changed the way I write code, and made me wildly efficient compared to before I used it. That doesn't mean I'm going to go and start browbeating people into using it. The git community seems to be blind to the notion that git (as wonderful as it is) might not be for everyone.
- snprbob86 17y ago
  All these people shouting about it are are spreading it by word of mouth and it has spread like wildfire. Maybe it is time to consider if it really is that good?
- FooBarWidget 17y ago
  How is an article on someone elses website "in-your-face"? Nobody's pointing a gun at you and forcing you to read it. If blogging about it is "in-your-face" then what do you consider an acceptable method to tell others about a great tool?
ebishop 17y ago
While I can understand how git is better for the majority of use-cases, I found that it was far less suitable than SVN for what I want to do. I used git for a while (3-6 months) and then switched BACK to using SVN. It's true I didn't experience pain until I started using git. That's when the pain started. First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic. Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus. For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers.
- joeyh 17y ago
  If adding a shell script to your development environment results in pain every time you need to set it up, that says you haven't automated setting up the environment. One great way to automate it is to put all such scripts (surely this would not be the only one?) and other files in a version controlled repository; then you just have one more thing to check out. (If checking out one more thing results in pain, you should think about automating the checkout too... This line of thinking has resulted in me keeping everything in git and using a single `mr` command (google will find it) to check out all my respositories when I'm setting up a new account.) Revision numbers are not impossible with DVCS; bzr has repo-local revision numbers. But once a number becomes longer than 3 digits, I cut and paste it anyway; if I'm already pasting, the longer size of git's sha1s doesn't matter.

oscardelben 17y ago

The article is indeed for people who are pretty satisfied with svn. I don't think of the article as a waste of time because there are many people who don't know what are the advantages of git over svn.

RyanMcGreal 17y ago

To borrow a concept from programming languages, svn is blub.

axod 17y ago
That's about as good an argument as saying only communists use svn. So basically your argument is that the only people who can have a valid opinion about the usefulness of different rcs's are those using git :/
- dasil003 17y ago
  I agreed with the first two sentences of your original post. People waste entirely too much time writing about git vs svn. However, you are absolutely wrong here. The blub argument is not that you must use git to have a valid opinion about git. It is that you must grok the power of the features. You could have a reasonable background of modern version control by using Mercurial, DARCS, BitKeeper, etc, even if it didn't inform you perfectly about what git can do (rebase -i anyone?). However if you've only used SVN or CVS then you are completely in the dark. I'm sorry but it's the indisputable truth. It's like someone who's never programmed in anything but Java, explaining how LISP macros are of no use to them. As if they would even know what a macro could do for them.
  - axod 17y ago
    ... and I'm absolutely aware of what git can do. I'm not making an uninformed choice here, I know the fun things git can do, and I'm sure if I switched to git, I'd probably spend all day playing with its awesome features, then I'd probably write a blog post proclaiming how awesome it is. Or, I could just continue using svn which perfectly fits my use case and does everything I need it to do. As I say, it stays out of my way and doesn't take any of my time up. You seem to assume everyone uses revision control in exactly the same way and that everyone has exactly the same needs/pain points/etc
    - dasil003 17y ago

compay 17y ago

I'm also surprised people are still arguing about this. I switched to Git so long ago I sometimes need to look at the man pages for SVN when I use it because I've forgotten how to do some things. IMHO unless you have a good reason to use SVN, you really should be using some kind of DVCS. SVN compared to Git/Mercurial/etc is like nano compared vim or emacs. I do definitely consider "I'm already using SVN and I'm happy" to be a completely valid reason to use SVN because people should be free to use what they like. But if that is your line of thought, keep in mind that you are making a concious decision to continue with a much less powerful tool and are not taking advantage of something that, if you put the time into learning it, would benefit you.

axod 17y ago
Still generalizing IMHO. Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs. Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.
- zaphar 17y ago
  Name a use case where svn is more suited than git is. I for one can't think of a single one. At most they might be equivalent. More likely git will be one of: * faster * more featureful I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
  - sid0 17y ago
    When you want to lock binary files as "being edited". DVCSes by design cannot lock files. edit: I'd also say that SVN integrates better with a lot of things than git/hg do.
  - axod 17y ago
    One off the top of my head: From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.

mechanical_fish 17y ago

I don't feel any pain. Have you asked your colleagues if your use of svn is causing them pain? Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said. But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later. So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools? P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.

doty 17y ago
How does git make programmer A want to disentangle the fix? How does git keep Programmer B from making changes against the wrong base? (Admittedly, git may make it easier to move that fix from the wrong base to the right one, but it doesn't make it harder to make the mistake; if anything, a prolifiration of branches an independent lines of development makes it easier to make that mistake, not harder.) How does git make merging easier? Doesn't it do a traditional three-way merge, just like svn? And it seems like in DVCS you have more merging, not less...
- 17y ago

steveklabnik 17y ago

> Wish people would quit with the "Tool X is always better than Tool Y". Most of the time, I would agree with you. In this case, DVCS is a superset of VCS, so it is _always_ better.

sid0 17y ago
Centralized VCSes can lock files. DVCSes cannot. Ergo, DVCSes are not a superset of centralized VCSes.
- steveklabnik 17y ago
  Couldn't the upstream repository just not accept changes to that file? I'm sure this could just be managed by some kind of commit hook.
  - sid0 17y ago
    Interesting. I hadn't considered that possibility. I'm more familiar with hg than with git, but from what I gathered in #mercurial, it should be possible to write a combined extension + a commit hook that: * allows people with appropriate permissions to lock and unlock files * sets locked files to read-only on pull from the canonical repository, so that users are warned beforehand that the files are locked * rejects commits that modify locked files except for by the person that holds the key There are a bunch of issues that need to be worked out, but I think the problem is tractable. Nice, thanks for the idea!
doty 17y ago
A superset is not always better. Consider domain-specific languages vs. general-purpose languages. You need to weigh the benefits of increased power with the drawbacks of additional complexity.
- steveklabnik 17y ago
  Ease of use is important, we certainly agree on that. But "git clone url" vs "svn co url" and "git commit -a" vs "svn commit" isn't significantly more complex.

DanielBMarkham 17y ago

Hear hear! Versioning is about 1/10th of software engineering, and it's about 1/1000th of running a successful startup. I wonder how many companies managed to survive in the bad old dark ages before we had git? </sarcasm> This incessant cheerleading is obnoxious. Source control is simply not that much of a time sink (or shouldn't be) to warrant all this attention. Work on making something people want, folks. Stop getting all wrapped up around the axle about some nifty new wizzbang tool.

uuilly 17y ago

I just moved from a 4 man svn project to a 4 man git project. It took me a month before I didn't feel like an ass in git. I'm still not sure what I have gained. I know git is so powerful and does so many things, but I'm a simple user. To me version control is like a doormat: I pass it really quickly on the way into the house. If that's what it is to you git will not open up a new world. In fact it will just take you longer to become proficient and waste time that could otherwise be spent coding.

jerf 17y ago
When you say you are a "user", are you not a programmer? If so, then you probably won't see much to be excited about. If you are a programmer and you aren't seeing how source control helps you (and it sounds like you weren't seeing any particular benefit with SVN either), then you either don't have much experience, or are dangerously close to being the type of programmer who repeats the same year ten times, rather than acquiring ten years of experience. You really need to work on internalizing what source control allows you to do, git, svn, or otherwise. Not knowing what source control is good for is like a furniture maker wondering what a lathe is good for, beyond turning a simple cylinder. (Among other things, if there was a Furniture News, that's not the sort of comment that ought to be getting upvotes...) Edit: Yes, nothing scores downmods like telling people that you need to know things to be a good developer. Guess what? You need to know things to be a good developer. Knowing what source control is and how to use it effectively is one of them. Downmodding me won't make that go away, nor will it magically make people who don't "get" source control better developers.
- uuilly 17y ago
  jerf, using the analogy of the furniture builder: -Your shop would be your OS. -Your wood would be your programming language. -Your lathe would be your IDE / text editor -Your broom would be your source control system. A furniture builder would use a broom to reset after a messy job and at the end of the day. That is about how I use source control. I've never worked on a huge open source project with lots of branching and merging. I've worked in small teams where we have one evolving version and that's all we really care about. SVN works fine for syncing and resolving conflicts. If SVN is a broom, Git is a complicated vacuum cleaner. Perhaps more powerful, but when I started using it, I took me 10x longer to clean the floor. I learned CVS, Rational Clearcase, MS Source Safe and SVN on the first day and spent very little time thinking about them afterwards. While I liked SVN the best, they all did their job well enough. I'm now good enough at git that it's not a time sink, but I'm not sure what I really gained from it. Furthermore, you may want to adjust your tone and try not to jump to conclusions. You probably can't intuit what kind of a person / developer I am from a single comment.