[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    clarification on git, central repositories and commit access lists
From:       Adam Treat <treat () kde ! org>
Date:       2007-08-20 6:52:32
Message-ID: 105191.19338.qm () web30711 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

Hi Linus,

I just watched your talk on git and wanted to ask for clarification on a few points.  \
Many of us in the KDE community are interested in git and some even contemplate using \
git as the official SCM tool in the future.  However, I think a few issues have been \
confused and want to see if you can clarify.

Your talk focused heavily on the evils of a central repository versus the benefits of \
a distributed model.  However, I wonder if what you actually find distasteful is not \
a central repository per se, but rather designing an SCM that relies upon \
*communication* with a central repository to do branching/merging or offline \
development.

After all, your repository acts as a de-facto central repository of the linux kernel \
in as much as everyone pulls from it.  Without such a central place to pull the linux \
kernel would not exist, rather what you'd have is a bunch of forks which perhaps \
merge with each other from time to time.

For any software project to exist as opposed to a bunch of forks I think you *have to \
have* a central repository from which everyone pulls, no?  Of course many branches \
might exist, but those branches must pull from a central repository if they want to \
share *at least some* common code.

A central repository is also necessary for projects like KDE to enable things like \
buildbots and commit mailing lists.  These tools are important to the way we work and \
provide for many eyes constantly reviewing changes to the codebase as well as regular \
regression testing across diverse platforms.  In the future, whether git or svn, I \
see no advantages in getting rid of a central repository from which everyone pulls.  \
I wonder whether you really disagree.

In your talk you also focus on the evils of commit access lists, comparing and \
contrasting with the web of trust the kernel uses where you have no commit access \
lists at all.  However, isn't the kernel model just a special case?  The linux kernel \
has a de-facto commit access list of one: you.

This might work well for the kernel, but I fail to see how this really reduces \
politics.  Many are still constantly pushing and arguing to merge their branches \
upstream into your repository.  Would having a central repository where you and all \
your trusted lieutenants push their changes really be very different?

The KDE community has a very large commit access list and it is quite easy to join.  \
Having a central git repository with a large set of committers would seem to map well \
with our community.  I fail to see any harm in this model.  The web of trust would \
still exist, it would just be much larger and more inclusive than the model the \
kernel uses.  I wonder if you disagree.

Another sticking point is the performance implications of a git repository managing \
something the size of the KDE project.  I understand the straightforward solution: \
just define content boundaries with a separate git repo for each submodule: \
kdelibs.git, kdebase.git, kdesupport.git, etc, etc.  And then have a super git repo \
with hooks that point to these submodules.  However, I think this leads to a few \
problems.

What if I want to make a commit to kdelibs that will require changes in other modules \
for them to compile.  I will no longer be able to make a single atomic commit with \
changes to multiple submodules, right?  Also, won't we lose history when moving \
files/content between submodules?  And how will we break up the existing history \
between all of these submodules?

Finally, a couple points...  CVS/SVN might be stupid and moronic, but I think it is \
good to note they are not nearly as bad as some other SCM's.  Many SCM's used by some \
of the largest codebases in the world are still lock-based.  If you think it is \
difficult to branch/merge using a central server, remember that some poor folks can't \
even *change a single file* without asking the central server for permission.

It is also good to note that a free distributed SCM was not available until recently. \
The kernel community might have had a special deal with BitKeeper, but the same \
didn't apply to all open source projects AFAIK.  When KDE moved to svn it was the \
best tool for the job.  That might have changed when git became easier to use, but at \
the time it was simply too big of a barrier for new developers and too new.  And from \
what I understand git support on other platforms is a recent development.

Cheers,

Adam


[prev in list] [next in list] [prev in thread] [next in thread]