3 ms·

The major win is that a DVCS decouples the "commit as save work-in-progress" from the "commit a carefully polished jewel of a changeset which will live for eter

by jbert 18y ago

The major win is that a DVCS decouples the "commit as save work-in-progress" from the "commit a carefully polished jewel of a changeset which will live for eternity in the revision history". i.e. you can commit locally frequently, and push refined changesets upstream. The best of both worlds. Other top benefits include sideways pushing (work on desktop A & B, push work-in-progress between them without polluting the central repo). Yes, you can get a lot of the DVCS benefits from giving people personal, scratch brances in a central CVS, but for various social and technical reasons that seems to rarely happen.

run4yourlives 18y ago
I suppose that's where I just don't understand things: What benefit does committing locally bring? Why not just not commit at all until you have that "carefully polished jewel"? Unless of course you're working on a change large enough to justify it's own branch, in which case the point is moot. The sideways push I get, but given that I use a laptop I find it irrelevant to me.
- DarkShikari 18y ago
  Because you no longer have to think much before committing. You don't have to spend hours reviewing the code and having others look over the patch before you push it to the main tree: you can just commit it locally and go work on something else. Then, later, you might get an idea on how to improve your previous change. You go and amend it. And so forth. Eventually, you have a set of changes that's ready to be committed and which you have used locally for long enough that you can tell it doesn't break anything obvious. Then, you go through the code review, and finally push the changes. With a completely centralized system, you have one of the following going on: A. You don't actually do code reviews before pushing changes, and trunk is broken half the time. B. You wait all the time on your changes being reviewed, and you can't commit them until they have been. C. You revert to tarballs and diffs for dealing with different changesets. I was forcibly pushed into using git from svn, but now I'd never go back: its simply so much easier to say "OK, I'm done with this change, I'll commit it!" and not have to wait for everyone else to be in the office/online/available to look at the changes before I do so. This is especially important when dealing with separate changesets that necessary depend on each other, where you can't merely make a new branch for the new change because it requires the old changes.
  - run4yourlives 18y ago
    Thanks for the reply. That certainly explains some clear benefit. That's the first time somebody's laid out for me in that fashion.

by jbert 18y ago

run4yourlives 18y ago

I suppose that's where I just don't understand things: What benefit does committing locally bring? Why not just not commit at all until you have that "carefully polished jewel"? Unless of course you're working on a change large enough to justify it's own branch, in which case the point is moot. The sideways push I get, but given that I use a laptop I find it irrelevant to me.

DarkShikari 18y ago
Because you no longer have to think much before committing. You don't have to spend hours reviewing the code and having others look over the patch before you push it to the main tree: you can just commit it locally and go work on something else. Then, later, you might get an idea on how to improve your previous change. You go and amend it. And so forth. Eventually, you have a set of changes that's ready to be committed and which you have used locally for long enough that you can tell it doesn't break anything obvious. Then, you go through the code review, and finally push the changes. With a completely centralized system, you have one of the following going on: A. You don't actually do code reviews before pushing changes, and trunk is broken half the time. B. You wait all the time on your changes being reviewed, and you can't commit them until they have been. C. You revert to tarballs and diffs for dealing with different changesets. I was forcibly pushed into using git from svn, but now I'd never go back: its simply so much easier to say "OK, I'm done with this change, I'll commit it!" and not have to wait for everyone else to be in the office/online/available to look at the changes before I do so. This is especially important when dealing with separate changesets that necessary depend on each other, where you can't merely make a new branch for the new change because it requires the old changes.
- run4yourlives 18y ago
  Thanks for the reply. That certainly explains some clear benefit. That's the first time somebody's laid out for me in that fashion.