Boost logo

Boost :

Subject: Re: [boost] DCVS vs CVS: call for constructivism
From: dag_at_[hidden]
Date: 2012-03-26 18:33:31


Edward Diener <eldiener_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk