Apache considered harmful

Then, OP argues ASF's processes are broken and a github project with one maintainer is so much easier... you really have to consider the scale of the average sourceforge (back in the day) project vs. apache even back then - and they have only grown from there, so no wonder a project hosted on github now is more "fun" to contribute to and work with because processes are probably pretty much non-existent and communication-paths and hierarchies are pretty much flat. The same goes for working at a small start-up vs. working at HugeFatCat Inc.

But one thing I cannot stand: arguing git over subversion. Yes both are great revision control systems but they are just meant for different applications. Where I am working, I would take subversion over git any day if all I really want is an absolutely sure-fire way of having a simple and easy to use central repository. I am in the unfortunate position to having met and working with quite a few people (programmers non-the-less) who have a hard time coping with basic CVS/SVN update-commit cycles - with git and mercurial offering you the option to commit but to your local changes first before actually committing your changes to the repository you checked out from (or another repository or...), this would have literally created havoc and confusion for my small team here... I know them, yes it sounds ridiculous, but I know I have saved myself a hell of a lot of trouble and headache. SVN is an absolutely perfect tool for the job if you do not need the de-centralization, on-the-go-commits and all the possibilities of creating custom processes in git with all its flexibility and features and options. SVN works just fine for what it is.

git and mercurial are not better,newer,shinier substitutes but different beasts altogether. (great, shiny, powerful and useful none-the-less) So could be please just let them peacefully co-exist and be thankful someone made them for us to make our lives easier?

His entire dislike of the Apache Foundation appears to be predicated on the fact that the organisation did not force every project to move to this blogger's favourite version control tool. Making a change as large as this requires many different things, but in particular:

1. Community change. How committers interact with each other when there are lots of forks is quite different to the current situation. That suits some projects and not others. Not every project at Apache will benefit. Some will. All who change will need to think long and hard about release processes, merging strategies and much more. Git encourages the idea that every commit or fork is completely equal to every other fork or commit. The Apache Foundation is built on the concept of meritocracy: commit rights are given in response to demonstrated skill. This is not an intractible problem with git, but new challenges need to be solved.

2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning.

3. Infrastructure. Hosting a large git repository with the level of downtime acceptable to Apache isn't something you do quickly. That needs planning and maintenance.

4. Toolsets. Lots of things in Apache are tied into subversion. From mailing list commit hooks to build servers and much more. Changing those things takes work.

5. Splitting the community. Right now the entire organisation's intellectual property is held in a single repository. Everyone knows where everything is to be found. Changing this simplicity requires a very good reason.

So what do we have now? A blogger who (it appears) doesn't actually contribute code to any Apache project. Telling other people how to run their organisation (which is wildly successful). And that they should change to this blogger's favourite new tool (they should have done it in 2008!) or face irrelevance.

If Apache moved every project to github tomorrow would that satisfy this blogger? More importantly, would that have caused this guy to commit high quality code toward one of the Apache projects? Or is he just blowing a lot of hot air about something he knows little?

And what brought on this great complaint? That the Apache Foundation is currently underway with trials for one project to see how git would succeed for their workflow. And to then evaluate its suitability for other projects across Apache.

Apache is not Github. That is, Apache is much more than a website, a couple of tools and a repository of code of random quality.

Disclaimer: I am an Apache member, but not speaking on behalf of Apache

a) a complete misunderstanding of how and why the ASF operates the way it does

or

b) a desire for sensationalist blog pieces with almost no factual content

The ASF is working with Git, it has been for years. It doesn't yet provide a canonical repository from which to make releases. This is due to a number of non-trivial technical issues introduced by the processes adopted by Apache projects.

The Apache infrastructure team believe that they have now solved those issues and are testing them in CouchDB. Assuming the CouchDB experiment is a success the ASF will be rolling out Git as the canonical repository to all projects that want it.

Once the ASF has mapped the tools to the processes we can all move on and stop wasting our time with this spurious argument.

Disclaimer: Unlike the author of this blog I do have access to all the discussions about Git in the ASF and I am one of the mentors of PhoneGap, a project mentioned in the article.

Git's ability to edit the history is a very useful tool. I don't think Subversion or any other VCS prevents you from editing the history either. Maybe they just don't provide tools for that so you'd have to hack the internal data structures of the VCS or something, but you actually want a tool to modify the history. Think about the situation where somebody accidentally pushed a secret private key or a database password to a public repository, you want it out of there! (there's a ton of examples of this in GitHub. git filter-branch is what you should do).

In order to provide "safe" history for Git, the commits must be cryptographically signed by their authors. This is vastly superior compared to trying to use some server side authentication kludge, which can be broken into. And the data structures of the VCS database can be modified, with a hex editor if all else fails. Cryptographic signing provides a guarantee against hex editor hacking too.

If I read one more "Git sucks because you can edit ancient history" comment from someone who doesn't understand the concept of crypto signing, I will cry.