Distributed version control? How winter 2007 of you. Let's try distributed bug tracking.

http://www.distract.wellquite.org/start

by pius • 18 years ago

7 9 18 years ago

distract.wellquite.org

schmoe• 18 years ago

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.

projectileboy2• 18 years ago

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?

jamesbritt2• 18 years ago

I think this may help

http://video.google.com/videoplay?docid=-2199332044603874737

rglullis• 18 years ago

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.

nradov• 18 years ago

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

Distributed version control? How winter 2007 of you. Let's try distributed bug tracking.

Related Stories