

Let’s talk about DVCS - niels
http://www.b-list.org/weblog/2008/jul/28/lets-talk-about-dvcs/

======
orib
What's different? I don't have to trust committers. People can commit to the
repository without having their changes affect my work until I want them to.
It's a pull model, instead of a push model, when you use it the way it was
intended.

The flexibility, of course, allows you to use a distributed version system
exactly the way you would with a centralized one.

------
defunkt
We hear so much about the technical advantages (speed, offline committing,
instant branching, cherry picking, rebasing) that we often forget the real
advantage of DVCS: the D. That this article starts with the technical
advantages makes me think we've done a bad job selling tools like Git and hg.

Yes, Rails still uses a 'central' development model. But it's trivial for me
to fork Rails then track development, add my own features, fix bugs, or go my
own route with a personal or corporate version of the framework. Many people
do this. Rails has almost 300 forks on GitHub alone. In fact, every time you
`git clone` Rails you fork it.

If someone has stopped maintaining a small library, you can fork it and take
over. It's now your library. Others can pull down your changes and watch your
development.

If you don't like the direction someone is taking their library, you can fork
it and head a new direction. And the two tracks can live in harmony. You can
even take changes you do like from the original library and merge them into
yours with ease.

These things happen all the time and are possible with a DVCS because of the
opinions (or rather, lack of opinions) present in software like Git. Yes, you
can add this stuff to Subversion - add offline committing, use shas instead of
revision #s, enable inline branching - but as soon as you do Subversion
becomes a DVCS.

For me, it's always been about the social aspect of DVCS. That is the
interesting part. The technical awesomeness is icing on the cake.

~~~
anotherjesse
Most of the time when I hear about pains of DVCS, it is when they are
attempting to use it in a non-distributed way - without first having learned
how to use the framework.

Learning git or hg as cvs/svn++ is REALLY bad. I've personally lived through
Flock using hg for several months only to abandon it for SVN (hg was version
0.6 and would eat our commits...) I've also had to help friends at companies
who jumped on git without knowing how to use it, and hearing horror stories
about everyone rebasing/rewriting history combined with a central repo.

Honestly it makes me not promote git as much since I don't want to deal with
the "svn++" mentality.

------
projectileboy
There are a few different things that click for me with git (e.g., local
access = lightning fast operations for those things I want to do all the
time), but I guess the single biggest win in my opinion is that the tool no
longer dictates workflow within a large organization.

Whether you realize it or not, if you've got a group of a thousand developers
and you say "let's keep our code in Subversion" (or ClearCase, or... etc.),
you've just made a whole host of decisions about how the individual project
teams are going to collaborate with one another.

Distributed version control systems let you consciously decide what the
workflow will be between project teams, and this hasn't been possible before.

~~~
endlessvoid94
"Whether you realize it or not, if you've got a group of a thousand developers
and you say "let's keep our code in Subversion" (or ClearCase, or... etc.),
you've just made a whole host of decisions about how the individual project
teams are going to collaborate with one another."

As mentioned in the article, what are these choices? What EXACTLY changes
about the way teams will collaborate? This seems to be his real question...

~~~
DougBTX
You may not have read this article before:
[http://moishelettvin.blogspot.com/2006/11/windows-
shutdown-c...](http://moishelettvin.blogspot.com/2006/11/windows-shutdown-
crapfest.html)

Here's a relevant quote from the article:

    
    
        In Windows, this [centralised] model breaks down simply 
        because there are far too many developers to access one 
        central repository. So Windows has a tree of 
        repositories: developers check in to the nodes, and 
        periodically the changes in the nodes are integrated up 
        one level in the hierarchy. At a different periodicity, 
        changes are integrated down the tree from the root to the 
        nodes. In Windows, the node I was working on was 4 levels
        removed from the root. The periodicity of integration 
        decayed exponentially and unpredictably as you approached
        the root so it ended up that it took between 1 and 3 
        months for my code to get to the root node, and some 
        multiple of that for it to reach the other nodes. It should
        be noted too that the only common ancestor that my team, 
        the shell team, and the kernel team shared was the root.
    

With a distributed system, it would be possible to send changes directly
between the two groups. You might have a problem keeping the whole Windows
source code repository stored locally on your development machine though.

------
silentbicycle
Storing all history locally changes several search operations from time-
consuming emergency techniques to immediate options.

Support for network structures besides "central server with commit haves and
have-nots" greatly reduces the amount of inherent politics and the seriousness
of forks.

Every repository is a _full backup_ , and could become a new primary server if
necessary. Even if you still use a "commit to central server" network
structure, this comes in handy.

~~~
LogicHoleFlaw
I like that DCVS makes the "commit to central server" idea a community
agreement rather than a technological limitation.

~~~
silentbicycle
Exactly. You can still use a DCVS _like_ a centralized system, if you want,
you just get automatic backups, faster searching, and load balancing for free.

------
rmanocha
For me, the biggest win about DVCS are offline commits. I (unfortunately) live
in a country where powercuts aren't uncommon. Also, broadband here is
expensive, and slow (I've only got a 384 kbps connection) so not having to hit
a central server for each one of my vcs related tasks helps out a lot.

------
kalid
If it's useful, I wrote a guide to DVCS here:

[http://betterexplained.com/articles/intro-to-distributed-
ver...](http://betterexplained.com/articles/intro-to-distributed-version-
control-illustrated/)

Pros: Everyone has a local sandbox, works offline, fast, great change
tracking, easy branches/merges, less software setup

Cons: no "revision" by default (ugly change guids), no central "always-on"
location by default

