4 ms·

If this is advertising, I want more of it. As an SVN curmudgeon, the first part of this tutorial finally persuaded me that I really, really need to give distrib

by matrix 17y ago

If this is advertising, I want more of it. As an SVN curmudgeon, the first part of this tutorial finally persuaded me that I really, really need to give distributed version control a fair trial. Joel pretty much nailed all my objections/complaints/whines about switching. But I also know the pain of merging all too well - a benefit that I hadn't really seen explained as persuasively before.

hypermatt 17y ago
It reads really funny right? I enjoyed reading it even though I already used Git and the GFX were great. This is how all technical guides should be
jamesbritt 17y ago
" But I also know the pain of merging all too well - a benefit that I hadn't really seen explained as persuasively before." FWIW, try to give a few DVCS tools a shot before settling on one. I was a big hg fan, and really didn't care to switch when my coworkers ganged up on me and decided that git was a better tool, but I think they were right. The git command line leaves much t be desired; hg was far more intuitive. But I would occasionally have merging issues with hg that were just too annoying (lost or missing file changes, for example) that I haven't had with git. But that's anecdotal, and I'm sure (if you follow enough dvcs flame/troll threads :)) you'll hear other stories about other tools. The upshot is to try a few to see which works best for your particular needs.
- vog 17y ago
  I've had the opposite experience: There are scenarios where Git reverts some changes unexpectedly and almost silently, if you don't take care. In contrast, Mercurial's strict "every merge is an explicit commit" principle saved me from a lot of problems. Regarding the command line interface: Darcs has still the best one. Well, Darcs has some performance issues, but its interactive dialog-based command line interface is outstanding. It is years old, but neither Mecurial nor Git come even close to it. So if you have a small project or a fast computer, you should definitely have a look at Darcs in addition to Mercurial and Git.
ezy 17y ago
This I don't get. The branching/merging thing seems to be overblown to me. The reason I'm switching is because I like the tools better, and you can be up and running with a repo in about 5 seconds. I think that's argument enough. There's less pain. But what is so different about merging in hg/git that merging a complex change from a branch is somehow made magically trivial? I mean, the tools for handling changes might be better because they are more modern, but the whole "changeset" thing seems to be hyperbole -- all (well, any good one) VCS's track changesets, that's what those revision numbers (or collectison of rev numbers) mean. :-)
- solutionyogi 17y ago
  Ezy, I understand where you are coming from. I used to think the same way. But once you have used git or Mercurial with their powerful branching/merging capabilities, you will never go back to anything else. Also, it's not that the tools aren't better, it's that git and Mercurial have different architecture which makes branching/merging easy and powerful. I would sincerely request you to not dismiss this 'branch/merge' phenomena. Once you understand their power, you would wonder why you ever managed to live with Subversion (or other centralized VCS). Searching on Google, I came across this example which will show you how powerful Git really is. [warning: PDF link] http://ietl.univ-lyon2.fr/sites/ietl/IMG/pdf/Git_merging_by_example.pdf http://ietl.univ-lyon2.fr/sites/ietl/IMG/pdf/Git_merging_by_...
- lallysingh 17y ago
  Oh the branching and merging can be big problems for some of us :-) The difference is that hg preserves the local commits as part of the upstream commit-set. That gives it a lot of information when making decisions about merging. SVN only has two versions of the file: what's in the server and yours. There's just less information to merge intelligently.
- nollidge 17y ago
  Joel hits on this on the first page (Subversion Re-education). My understanding, as a DVCS virgin, is that you commit far more often (to your local repository) than with Subversion, and so Hg can more intelligently merge things. My guess is that there is some intelligence that can tell that "foo missing there, and foo added here" is actually just "foo moved from there to here", unlike SVN, which attempts no such heuristics. I hope someone can correct me if I'm wrong here :)

by matrix 17y ago

hypermatt 17y ago

It reads really funny right? I enjoyed reading it even though I already used Git and the GFX were great. This is how all technical guides should be

jamesbritt 17y ago

" But I also know the pain of merging all too well - a benefit that I hadn't really seen explained as persuasively before." FWIW, try to give a few DVCS tools a shot before settling on one. I was a big hg fan, and really didn't care to switch when my coworkers ganged up on me and decided that git was a better tool, but I think they were right. The git command line leaves much t be desired; hg was far more intuitive. But I would occasionally have merging issues with hg that were just too annoying (lost or missing file changes, for example) that I haven't had with git. But that's anecdotal, and I'm sure (if you follow enough dvcs flame/troll threads :)) you'll hear other stories about other tools. The upshot is to try a few to see which works best for your particular needs.

vog 17y ago
I've had the opposite experience: There are scenarios where Git reverts some changes unexpectedly and almost silently, if you don't take care. In contrast, Mercurial's strict "every merge is an explicit commit" principle saved me from a lot of problems. Regarding the command line interface: Darcs has still the best one. Well, Darcs has some performance issues, but its interactive dialog-based command line interface is outstanding. It is years old, but neither Mecurial nor Git come even close to it. So if you have a small project or a fast computer, you should definitely have a look at Darcs in addition to Mercurial and Git.

ezy 17y ago

This I don't get. The branching/merging thing seems to be overblown to me. The reason I'm switching is because I like the tools better, and you can be up and running with a repo in about 5 seconds. I think that's argument enough. There's less pain. But what is so different about merging in hg/git that merging a complex change from a branch is somehow made magically trivial? I mean, the tools for handling changes might be better because they are more modern, but the whole "changeset" thing seems to be hyperbole -- all (well, any good one) VCS's track changesets, that's what those revision numbers (or collectison of rev numbers) mean. :-)

solutionyogi 17y ago
Ezy, I understand where you are coming from. I used to think the same way. But once you have used git or Mercurial with their powerful branching/merging capabilities, you will never go back to anything else. Also, it's not that the tools aren't better, it's that git and Mercurial have different architecture which makes branching/merging easy and powerful. I would sincerely request you to not dismiss this 'branch/merge' phenomena. Once you understand their power, you would wonder why you ever managed to live with Subversion (or other centralized VCS). Searching on Google, I came across this example which will show you how powerful Git really is. [warning: PDF link] http://ietl.univ-lyon2.fr/sites/ietl/IMG/pdf/Git_merging_by_example.pdf http://ietl.univ-lyon2.fr/sites/ietl/IMG/pdf/Git_merging_by_...
lallysingh 17y ago
Oh the branching and merging can be big problems for some of us :-) The difference is that hg preserves the local commits as part of the upstream commit-set. That gives it a lot of information when making decisions about merging. SVN only has two versions of the file: what's in the server and yours. There's just less information to merge intelligently.
nollidge 17y ago
Joel hits on this on the first page (Subversion Re-education). My understanding, as a DVCS virgin, is that you commit far more often (to your local repository) than with Subversion, and so Hg can more intelligently merge things. My guess is that there is some intelligence that can tell that "foo missing there, and foo added here" is actually just "foo moved from there to here", unlike SVN, which attempts no such heuristics. I hope someone can correct me if I'm wrong here :)