I am a big fan of DVCS systems, so I felt the need to chime in. See below. On 07/06/2007, at 16:21, David Abrahams wrote:
on Wed Jun 06 2007, troy d straszheim <troy-AT-resophonic.com> wrote:
[...]
* commit/branch/merge locally (not in the 'central' repository)
Interesting the emphasis on git's being distributed... there is no 'central repository'.
This part I have some trouble buying. In Linus' world, *his* repository is central... well, at least, it's the master from which releases are spun. In a project where we don't have a single arbiter for what goes into a release, I'm not sure we can have a master.
It is true that, by definition, there is no central repository. But by convenience, and for "big" projects, there will always be a more- or-less central repository. I have yet to see a project using a DVCS that does not declare a specific server to be the central one. (But, for example, I maintain some personal files in a DVCS system and I have no "central" repository; I just sync all the ones I have from time to time to get the updates.) But that's a good thing. This "central" repository has the blessing from the project maintainers, and it is supposed to contain decent code because only "official developers" are allowed to push to it after reviewing what they are pushing. However, everybody is free to start its own public repository if he wants to, to publish his changes. And this is easier than ever: no need to deal with patches, tarballs, or any other way to simply distribute changes for a project. Just pull from there and you get this or that experimental or non-official work. And what many people fails to realize: a DVCS may not bring _you_ (the "official" developers) any advantage over a centralized one. But it does really bring advantages to outsiders. They can just clone the central repository, do any changes to it without having to make them public, and painlessly keep it in sync with the master copy at the central repository. (I'm currently doing that to maintain some changes I'm working on for Linux/PS3.) Imagine, for example, the developer of a new library for Boost. He could integrate its library straight into the repository (a local copy, that is) from the very beginning and develop it in-place. Even when doing so, he could easily sync with the latest changes on the server *without losing any history*. And when somebody had to review it, he could just pull from his modified tree and get a modified Boost distribution with the extra library built-in. Later on, after this new library had been reviewed, the maintainers of the central repository could just have to pull from this developer's repository to get the new library *and* all associated development history. And at last, I'd like to suggest you to look at Monotone too (http:// www.monotone.ca/); its tutorial is enlightening -- it convinced me after a quick read that DVCS were just The Way to go. (Or if you want to play some more with Git, use the Cogito interface, which is simpler and more user-friendly, yet remains compatible with Git at the server level.) Kind regards, -- Julio M. Merino Vidal <jmmv84@gmail.com>