3 ms·

"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

"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.

georgieporgie 15y ago
DVCS eliminates this painful choice. Commit as often as you like on your local repo I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox. I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch. How is my process any different than using Git?
- wnight 15y ago
  Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc. Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete. Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc. And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie. tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.
  - georgieporgie 15y ago
    In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness Huh? Branching code in no way affects the code that has been branched. Instead of a flat directory as your sandbox you've got a full VCS at your disposal I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem. So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.
    - wnight 15y ago
      > Branching code in no way affects the code that has been branched. Usually it requires a repo admin - hence "team awareness". > So far, the only advantage I see to Git is the ability to make offline commits That's more important than you imagine. It also means nothing takes longer than a few seconds - branching, diffing, committing... > I don't get it. I can make as many branches in Subversion as I want. But you can't do it offline. You can't even check-in without the central server, let alone make and use branches, merge them, share them with another dev, etc. When you're offline you aren't using a VCS at all. > presumably they sync when I have a network connection Hah, no. That's half the fun.

georgieporgie 15y ago

DVCS eliminates this painful choice. Commit as often as you like on your local repo I use Subversion or CVS. When I'm coding on a team, we're usually working on a branch of the code. Additionally, I'm typically working on my own branch of that branch, which is my own sandbox. I check in whenever it makes any sense. My only rule is that the code must compile. When I reach a point where I want my peers to receive my code, I merge to the team's branch. How is my process any different than using Git?

wnight 15y ago
Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc. Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete. Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc. And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie. tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.
- georgieporgie 15y ago
  In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness Huh? Branching code in no way affects the code that has been branched. Instead of a flat directory as your sandbox you've got a full VCS at your disposal I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem. So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.
  - wnight 15y ago
    > Branching code in no way affects the code that has been branched. Usually it requires a repo admin - hence "team awareness". > So far, the only advantage I see to Git is the ability to make offline commits That's more important than you imagine. It also means nothing takes longer than a few seconds - branching, diffing, committing... > I don't get it. I can make as many branches in Subversion as I want. But you can't do it offline. You can't even check-in without the central server, let alone make and use branches, merge them, share them with another dev, etc. When you're offline you aren't using a VCS at all. > presumably they sync when I have a network connection Hah, no. That's half the fun.