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