Apache Subversion to Migrate to Git

Update as many expected, this was an elaborate April Fools hoax made by many at the Apache Software Foundation. Being closed "Not a problem", Greg comments:

Resolving as "Not a problem". We sure as hell don't want to do this. :-)

My major thanks to [~jfarrell] for the concept.

And plenty of thanks to all of my co-conspirators on this issue. Yes.. even my antagonist [~jimjag] was in on the ruse :-) … the Infra team handled this with perfect aplomb. And the Directors and Exec Officers came in with a perfect level of wrath. Our Subversion teammates showed a great sense of community and circling the wagons… Thank you all for making this work!!!

Although this seems like a big change, in fact the Git repositories at Apache have been mirroring projects for some time using the unidirectional git-svn bridge. So the Apache SVN Git repository has been available for some time, and is browsable at GitHub already. The significant change is that in future the Git repository will be read-write for Apache committers, and the existing SVN repository will become locked.

New changes coming in the SVN client for 1.9 will allow the ra_git module to check out and work with Git repositories using the SVN client. This work is being developed in the ra-git branch, and provides (local) svn repository identifiers based on upstream git commits. Existing SVN tools will be able to use this both as a local checkout repository format and as a means to commit to a central Git server; in essence, it's a Git client with an SVN command line interface. Unlike the existing git-svn support, this uses Git natively between the client and server (and probably caches the Git repository locally on the client side) but continues to allow tools to locally operate on SVN checkouts.

Many of the commenters on the thread are less concerned about the irony of hosting SVN on Git as much as the private events that led to this occurring. Jim Jagielski, co-founder of the Apache Foundation expressed concerns that the vote was taken by the PMC behind closed doors, instead of the open democracy that Apache is known for. Even though Greg didn't vote for it, it was taken by the PMC for the Subversion project:

Look. The short of it is: the Apache Subversion project chose this. We want to get our stuff coded and released. For our backend, we don't need the super-huge repositories that Subversion supports. Our project stores some binaries, but we can make Git work for us. We have no need for Subversion's fine-grained authorization ... shoot. We allow ALL ASF committers access to our repository. There are no barriers to the migration here, and some of the stuff that Infra has done for integration with GitHub? Pretty cool. Positives, and only little negatives.

Don't get me wrong. I see the benefits. As the VP, I gotta represent the project. I really DO NOT LIKE this decision. But that is not for me to decide, and it is not for you (Jim/Rich) to decide for us. It is a decision of the PMC. Sure... they held the vote in private. But that does NOT deny the result of their vote. Pushing this vote to dev@ would simply incite riot. The people who have the voting power would NOT CHANGE.

So. As the VP of the Apache Subversion project, I opened this ticket. The Infrastructure team is moving on this ticket. If you, Rich, or any other Director/Officer have a problem with that, then bring it up at our April Board meeting. Otherwise, get out of this ticket. As Pilato and Tony have noted: this is not the forum.

With the conversion already underway and testing being done on the Git repository, the process more than the decision is under the spotlight.

Subversion remains the single biggest version control system, but is being rapidly replaced with Git in the open-source community; the decision to move the source for the Subversion implementation itself is an acceptance of that fact. But Subversion still remains large in enterprises and inertia is always present when moving repository types. What is clear is that Git is becoming a winner on the back-end, with the SVN client able to check out either SVN repositories or Git repositories.

What do you think of the decision to move the Subversion repository over to Git?

...why they prefer GIT as a backend. In addition there are reasons why SubVersion is a better fit for some enterprises (i.e. fine grained access control for organizations that haven't discovered collective code ownership).

However as an outsider two things struck me:- SubVersion seems to be signalling its own end - sad but perhaps necessary- The discussion under: issues.apache.org/jira/browse/INFRA-7524 was really nasty and makes me see why many people have been turned off open source.

Sad that electronic communication brings out the worst in people and not the best :-( Sad that SubVersion is slowly dying.

The poor behavior that seems to be ubiquitous in the Open Source community is a large part of why I left the *nix platforms. If I needed help, it was almost always at the level of the learning curve where a dismissive "you shouldn't need that" was the universal answer. I wish I could say it was profit motive or something, but I don't find that sort of toxic attitude in other communities.

I don't agree, though, that SVN is ending just yet. GIT is getting a larger swath of the market because it has advantages in smaller projects, but SVN still covers areas that GIT does not.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.