clarification on git, central repositories and commit access lists

[Raúl Sánchez Siles]

 Hello!

Adam Treat wrote:

> 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.
> 

 I've followed this thread quite interested, but so far I don't know why it
seems to be git the only alternative. So the topic keeps going, from my
POV, from remain in svn or move to git. I understand dates are not defined
yet,BTW.

  Alternatively the discussion could be central SCM vs distributed SCM, but
I guess all people here knows that there are others distributed SCM as
mercurial or monotonic.

  After having noticed about the thread, I went to #revctl where I had a
talk about the different distributed SCM tools. The impressions were that
some of them like bzr or darcs are not yet so mature to handle such a big
project. Monotonic had been there for some time and even Linus, before
diving into git development, evaluated it. He discarded it the first day,
being the performance quite far from good. Nowadays it should be much
better, but still has some problems compared to git and mercurial.

  These 2 left (git[1] and mercurial[2]) are the only 2 I have tried more or
less comprehensively, git a little more. I'm not an expert on SCM, but
after the conversation on #revctl looks like _git_ is very mature, stable,
performant, while still have some cons.

  _Mercurial_ has a base as stable as _git_, it's also quite performant,
written in python (using some C part for optimisation) and maybe has still
some features to come or in their first implementation.

  _Mercurial_ is said not to have the huge amount of commands that _git_
makes available. On _git_ most people end up re-reading the man pages,
while on _mercurial_ people sticks to a few set of them. Documentation is
very good on both[3][4].

 Regarding disk space usage on big projects, _git_ will eventually take a
lot of disk space of you don't "take care" of the database, you need to do
repack and cleaning with a certain frequency. This happens because _git_
stores every commit on a file, when you do repacking these objects are
grouped together into a single file, adding cleaning to this you end up
freeing disk space somehow. The _mercurial_ way to store database is
different, it will only take at most 2 files for each file on the
repository and there is where it'll store all the information, so database
will always keep to a reasonable space, and this doesn't mean less
performance, which I've been told it's generally quite the same.

  _git_ development seems to be totally tied to Linux kernel development,
IMHO this could lead some reluctancy to include features needed by other
projects. _Mercurial_ is moving in a fast pace there, they have implemented
sort of local branching (unavailable up to some time ago) called "named
branching", also they are working on including those interesting features
they see on others SCM.

 A good point on _git_ is that there are quite usable tools to examine
graphically the layout of the branching and committing, like qgit (based on
Qt). _mercurial_ has some, but is not there yet. BTW, taking into account
the mercurial devels to /copy/ good features on other projects I'd say
_mercurial_ and _git_ would have walked the same distance soon.

  One of the reasons to migrate to DSCM was the ability to do development
offline. Well, if you use _git_ you need internet access to some server
where you could do the fetching and pushing. On _mercurial_ is possible to
bundle all the database into a single file which you could send using, e.g.
e-mail. This would have some advantages, IMHO.

  As a conclusion, I think _mercurial_ and _git_ are both there. When you
ask about which one is better, you will be told that depends on the details
of your project, and I think it's because they are so slight differences
that is difficult to take a decision.

> 
> 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.
> 

  This supports the idea that the discussion is still central, vs
distributed. I think that has been covered in depth along the thread.

> 
> 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.
> 

  And I think the point now is exactly on how difficult would be moving into
distribute. This would divert some resources into managing the repository
tasks, people would have to learn a new tool philosophy. But I think on the
mid-run the migration could be good for the project, having a better tools
would improve the development flexibility.

> Cheers,
> 
> Adam

[1]http://git.or.cz/
[2]http://www.selenic.com/mercurial/wiki/
[3]http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
[4]http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial

HTH,

-- 
Raúl Sánchez Siles