6 ms·

Joel Spolsky had the same concerns about Git when he first started using it. He changed his mind and wrote a great post on why distributed version control is wa

Joel Spolsky had the same concerns about Git when he first started using it. He changed his mind and wrote a great post on why distributed version control is way better than SVN. http://www.joelonsoftware.com/items/2010/03/17.html http://www.joelonsoftware.com/items/2010/03/17.html He also happened to write a tutorial for mercurial that explains the same concepts. The tutorial is linked to at the very end of the article.

elviejo 14y ago
Hg Init: a Mercurial tutorial by Joel Spolsky http://hginit.com/ http://hginit.com/ It's a pretty good tutorial. But to me the mere fact that there are so many posts on How-to use a tool that is basic in a programmers arsenal, tells me that DVCS are a solution that lacks usability.
- nitrogen 14y ago
  We are talking about programming tools here, not tools for home kitchen chefs to track their recipes. A little intelligence and hard work on the part of the user is expected.
  - GrumpySimon 14y ago
    No that's just programmer masochism. If a tool is easy to use, then I get whatever I needed it for done, and done quickly. I can then move on to doing more interesting things (e.g. programming) rather than wrestling with the tool.
  - regularfry 14y ago
    Intelligence can be expected. Hard work should be unnecessary.
    - chris_wot 14y ago
      Interesting non sequitur.
      - regularfry 14y ago
        Why do you say that?
        chris_wot 14y ago
        Because it does not follow that if you are intelligent then you will not have to do any hard work. Edit: appear to have annoyed someone with that comment! But do go on - prove to me how high intelligence means that you don't need to do hard work, which is the proposition of the OP.
        regularfry 14y ago
        > Because it does not follow that if you are intelligent then you will not have to do any hard work. I don't think anyone's said that, or tried to say it (least of all me), at any point.
        chris_wot 14y ago
        You seemed to. You said "intelligence can be expected. Hard work should be unnecessary". What did you actually mean? I apologise if I misunderstood what you were saying!
        regularfry 14y ago
        I'm saying that while it may be valid to assume intelligence on the part of your users, that doesn't make it valid to make them work hard. I'm not saying that intelligence gets you out of hard work, I'm saying that it shouldn't necessarily get you into it - and from where I'm sitting, git requires both where it should only require one.
        chris_wot 14y ago
        Ah. I'm following you finally. Yes, I agree that unnecessary hard work shouldn't be needed.
  - SiVal 14y ago
    We are talking about programming tools here. A little intelligence and hard work on the part of the DESIGNER of the tools is expected.
- philwelch 14y ago
  Really? How many how-tos are there on text editors, programming languages, build systems, deployment systems, unit testing frameworks, frameworks, APIs, libraries, debuggers...?
  - bermanoid 14y ago
    I spend at least an order of magnitude, if not several, more time with each of those things than I do with a goddamn version control utility. I put in effort where it's worth it. Version control doesn't even come close to hitting the top of that list.
    - philwelch 14y ago
      You build and deploy ten times as often as you commit? Apparently you really don't think version control is worth it!
      - einhverfr 14y ago
        He said he spends ten times more time on building than on managing revision control. That doesn't mean 10x more deployment or development. On the other hand, I can tell you we have almost 10x more downloads than we have svn commits ;-)
        chris_wot 14y ago
        There is very little that is hard with managing your source code on your local workstation. To commit any changes, you type in: git commit -a -m "thing that I changed" To branch, it's: git checkout -b newbranch To switch back to the master branch, you just type in: git commit -a -m "changes made on branch" git checkout master To merge in that branch, should you so wish to do so, then you type in: git merge newbranch What is exactly so hard about that?
- sigkill 14y ago
  Ah, so it's by Joel. I tried Git but failed miserably with it. It could probably be attributed to the lack of quality tutorials at that time. I then thought, "Fuck it, let's try Mercurial" and stumbled upon hginit. That is one awesomely written tutorial. I use mercurial for my programming needs and find it totally intuitive to use. I definitely found it easier than git, but that could be possibly chalked up to my bad introduction to git.
  - 2muchcoffeeman 14y ago
    I tried Hg first and failed. Then I tried git and for some reason worked it out. DVCS concepts are hard when you're used to SVN.
    - sigkill 14y ago
      Hmm. I can't really comment on that since I've never used SVN. I was kind of lucky to jump directly into DVCS. The reason why I'm comfortable with Hg is because at the initial/first step the only commands I was told to remember (by hginit.com) were `hg commit` and `hg init`. Slowly, from there I took on a steady pace and grew comfortable with it. Currently on Windows I use tortoiseHg and bitbucket (I'm strictly a hobbyist coder only). When I tried to learn Git (before Hg), I looked for tutorials but everything was all over the place and maybe they introduced too much too soon. Anyway, at the end of the day I find Hg good enough for my usage - init, commit, push, pull so far.
  - tedunangst 14y ago
    Personally, I think anyone familiar with cvs or svn can pick up hg really easily. The commands and concepts in hg map onto equivalents in cvs very nicely. My mental model of hg is just cvs + cvsync. Done. git does not work like that. It's like each command was cut in half and recombined differently, like interlaced video or something. It's all there, it's just harder to recognize.
einhverfr 14y ago
"Way better" at what? The thing that people need to get through their head is that distributed version control is a whole different concept. There are some things it is great at. There are some things it sucks at. Centralized version control is great at some other things, and lousy at some other things too. I am thinking for example that if you are going for a PA-DSS-certified application, git, particularly with the ability to rewrite history, is going to be a problem, but dvs generally will provide more problems in assuring the auditor that you can locate, trace, and take corrective action if someone introduces a security issue (perhaps intentionally) into your application. I don't see git really working in that environment. On the other hand, if you have a lively project that everyone is experimenting with and you need to merge patches occasionally to create a stable release, yeah, it's much better.
- Aga 14y ago
  Why would dvcs cause problems for auditors? For any given project, no matter how distributed the development, you will have a "blessed" repository, from which the official releases are made. The history of this "blessed" repository is made not rewritable, even if anyone can push new stuff to it. The config files and hooks can be made writable by only admins. Or you use a maintainer model, where the "blessed" repository is not even pushable. A maintainer (or a group of them) chooses what he merges in.
pgeorgi 14y ago
A post why DVCS are better than SVN doesn't state anything about the qualities of git (unless it's actually about git, of course). I have concerns about git and used distributed version control years before git existed.

elviejo 14y ago

Hg Init: a Mercurial tutorial by Joel Spolsky http://hginit.com/ http://hginit.com/ It's a pretty good tutorial. But to me the mere fact that there are so many posts on How-to use a tool that is basic in a programmers arsenal, tells me that DVCS are a solution that lacks usability.

nitrogen 14y ago
We are talking about programming tools here, not tools for home kitchen chefs to track their recipes. A little intelligence and hard work on the part of the user is expected.
- GrumpySimon 14y ago
  No that's just programmer masochism. If a tool is easy to use, then I get whatever I needed it for done, and done quickly. I can then move on to doing more interesting things (e.g. programming) rather than wrestling with the tool.
- regularfry 14y ago
  Intelligence can be expected. Hard work should be unnecessary.
  - chris_wot 14y ago
    Interesting non sequitur.
    - regularfry 14y ago
      Why do you say that?
      - chris_wot 14y ago
        Because it does not follow that if you are intelligent then you will not have to do any hard work. Edit: appear to have annoyed someone with that comment! But do go on - prove to me how high intelligence means that you don't need to do hard work, which is the proposition of the OP.
        regularfry 14y ago
        > Because it does not follow that if you are intelligent then you will not have to do any hard work. I don't think anyone's said that, or tried to say it (least of all me), at any point.
        chris_wot 14y ago
        You seemed to. You said "intelligence can be expected. Hard work should be unnecessary". What did you actually mean? I apologise if I misunderstood what you were saying!
        regularfry 14y ago
        I'm saying that while it may be valid to assume intelligence on the part of your users, that doesn't make it valid to make them work hard. I'm not saying that intelligence gets you out of hard work, I'm saying that it shouldn't necessarily get you into it - and from where I'm sitting, git requires both where it should only require one.
        chris_wot 14y ago
        Ah. I'm following you finally. Yes, I agree that unnecessary hard work shouldn't be needed.
- SiVal 14y ago
  We are talking about programming tools here. A little intelligence and hard work on the part of the DESIGNER of the tools is expected.
philwelch 14y ago
Really? How many how-tos are there on text editors, programming languages, build systems, deployment systems, unit testing frameworks, frameworks, APIs, libraries, debuggers...?
- bermanoid 14y ago
  I spend at least an order of magnitude, if not several, more time with each of those things than I do with a goddamn version control utility. I put in effort where it's worth it. Version control doesn't even come close to hitting the top of that list.
  - philwelch 14y ago
    You build and deploy ten times as often as you commit? Apparently you really don't think version control is worth it!
    - einhverfr 14y ago
      He said he spends ten times more time on building than on managing revision control. That doesn't mean 10x more deployment or development. On the other hand, I can tell you we have almost 10x more downloads than we have svn commits ;-)
      - chris_wot 14y ago
        There is very little that is hard with managing your source code on your local workstation. To commit any changes, you type in: git commit -a -m "thing that I changed" To branch, it's: git checkout -b newbranch To switch back to the master branch, you just type in: git commit -a -m "changes made on branch" git checkout master To merge in that branch, should you so wish to do so, then you type in: git merge newbranch What is exactly so hard about that?
sigkill 14y ago
Ah, so it's by Joel. I tried Git but failed miserably with it. It could probably be attributed to the lack of quality tutorials at that time. I then thought, "Fuck it, let's try Mercurial" and stumbled upon hginit. That is one awesomely written tutorial. I use mercurial for my programming needs and find it totally intuitive to use. I definitely found it easier than git, but that could be possibly chalked up to my bad introduction to git.
- 2muchcoffeeman 14y ago
  I tried Hg first and failed. Then I tried git and for some reason worked it out. DVCS concepts are hard when you're used to SVN.
  - sigkill 14y ago
    Hmm. I can't really comment on that since I've never used SVN. I was kind of lucky to jump directly into DVCS. The reason why I'm comfortable with Hg is because at the initial/first step the only commands I was told to remember (by hginit.com) were `hg commit` and `hg init`. Slowly, from there I took on a steady pace and grew comfortable with it. Currently on Windows I use tortoiseHg and bitbucket (I'm strictly a hobbyist coder only). When I tried to learn Git (before Hg), I looked for tutorials but everything was all over the place and maybe they introduced too much too soon. Anyway, at the end of the day I find Hg good enough for my usage - init, commit, push, pull so far.
- tedunangst 14y ago
  Personally, I think anyone familiar with cvs or svn can pick up hg really easily. The commands and concepts in hg map onto equivalents in cvs very nicely. My mental model of hg is just cvs + cvsync. Done. git does not work like that. It's like each command was cut in half and recombined differently, like interlaced video or something. It's all there, it's just harder to recognize.

einhverfr 14y ago

"Way better" at what? The thing that people need to get through their head is that distributed version control is a whole different concept. There are some things it is great at. There are some things it sucks at. Centralized version control is great at some other things, and lousy at some other things too. I am thinking for example that if you are going for a PA-DSS-certified application, git, particularly with the ability to rewrite history, is going to be a problem, but dvs generally will provide more problems in assuring the auditor that you can locate, trace, and take corrective action if someone introduces a security issue (perhaps intentionally) into your application. I don't see git really working in that environment. On the other hand, if you have a lively project that everyone is experimenting with and you need to merge patches occasionally to create a stable release, yeah, it's much better.

Aga 14y ago
Why would dvcs cause problems for auditors? For any given project, no matter how distributed the development, you will have a "blessed" repository, from which the official releases are made. The history of this "blessed" repository is made not rewritable, even if anyone can push new stuff to it. The config files and hooks can be made writable by only admins. Or you use a maintainer model, where the "blessed" repository is not even pushable. A maintainer (or a group of them) chooses what he merges in.

pgeorgi 14y ago

A post why DVCS are better than SVN doesn't state anything about the qualities of git (unless it's actually about git, of course). I have concerns about git and used distributed version control years before git existed.