
Distributed version control?  How winter 2007 of you.  Let's try distributed bug tracking. - pius
http://www.distract.wellquite.org/start
======
schmoe
Haha, I'd bet real money that > 75% of people who read this site still use a
centralized VCS, most likely SVN. The pace of change is glacial.

~~~
projectileboy
This is not a troll - could someone please explain to me why I might use Git
instead of SVN? With Git, wouldn't I still need to merge all the streams
through some "offical" repository before I release version x of the product?
And if I'm doing that, then what's the difference?

~~~
rglullis
The point of the distributed approach is precisely that you eliminate the need
for a "official" repository.

If it seems pointless, consider a scenario where you have three separate teams
(A, B, C) working on a product.

In a centralized approach, you'd want to create a branch for each team, have
them working on their exclusive branch and have each of them make a merge to
the main branch. If you are responsible for the "main" repository, you need to
make three merges, one for A, one for B, one for C. This is hard and gets even
harder when the number of teams grows.

In a distributed approach, each team is able to pull stuff from the other
teams any time and as they see fit. In that case, if you are the responsible
for the "main" repository, you could establish a policy where you will only
pull code from the C tree, and let C be responsible for pulling from B, and B
from A. With this approach, each team is responsible only for one merge.

~~~
mechanical_fish
And yet, even if you are antisocial, and would never dream of setting up a
baroque collection of three independent teams, git is awesome.

You can have repositories all over the place. Creating or cloning them is
about as hard as copying a file. You can make one for any directory in a few
seconds. You can create them wherever you want on your hard drive. You can
back them up by dragging and dropping.

You can create one repository for (e.g.) the official release version of
Drupal, clone that to another repository that also includes some important
modules, then clone that repeatedly every time you start a project. To upgrade
Drupal, upgrade the first repository and then pull the changes forward to all
the others.

The branching support works very well and is easy to figure out. If you touch
a few files and then have second thoughts, you can stash all your changes in a
branch and then go back to the original state. You can screw around with your
source code with complete confidence.

Git repositories are non-magical -- each one is fully contained inside a
plain-old directory. If you do somehow manage to screw one up beyond
recognition, just restore an old version from backup. You won't lose anyone
else's changes, because each local repository is _exclusively yours_. You
won't run the risk of corrupting other projects, because each repository is
_local_ and includes just _one_ project.

No server configuration, unless you really want to share with the world (and
gitosis makes that easy).

------
nradov
Ho hum. We've had this since 1996 with a custom Lotus Notes/Domino
application.

