Edward Diener <eldiener@tropicsoft.com> writes:
I do hear general reasons why some people are more comfortable with a DVCS but since switching is going to cause me to have to learn a new set of techniques for working with version control and Boost libraries, while I am already quite comfortable with the current SVN system and its capabilities, you can understand why I do not see the reason for having to make this change.
It's useful to separate features that are an improvement over SVN while not being DVCS-oriented from features that are only available in a DVCS. As a git user, I would list the following in the first class: - git stash, which helps a lot when an interrupting issue takes you off into a separate project (usually a bugfix) - The index, which helps separate what you've changed from what you will commit (it is the index that allows cools things like "git add -i") - A better merge algorithm git features which depend on a DVCS model include: - Truly private branches (i.e. no one ever sees them or even knows they exist) -- these are often called "feature" or "topic" branches - git rebase, which lets you explore a line of development and clean up the history after the fact - First-class support for vendor branches/upstream code drops The above is just a sample, the things that popped into my head right away. There are other, more subtle advantages to git over svn. It's important to stress that each of these features, whether necessitating a DVCS model or not, exist in git and DO NOT exist in svn. So from a practical standpoint, it doesn't matter whether one buys into the DVCS model. The features are not in svn and so should be counted as a git advantage. A big one, IME. git can be used in a perfectly centralized way. I don't know why one would want to do that, but it is possible. -Dave