April Fools: migrate Apache Subversion project over to the git repo | Hacker News Reader

April Fools: migrate Apache Subversion project over to the git repo

issues.apache.org

170 pointsyuvadam98 comments

"gone wrong"?

Considering the lameness[1] of april fools jokes on the interwebz in the past few years, this was refreshingly amazing.

I can't remember the last time I was actually tricked by an internet april fools joke; this one totally got me. I believed it until I saw this HN post.

A+ for fantastic execution.

1. https://news.ycombinator.com/item?id=7507297

Unfortunately, the reason it worked was (as someone who uses both svn and git professionally) it was entirely plausible that the subversion devs would want to use git.

Indeed, if nothing else than for access to the Github community.

Github has supported SVN access since April 1, 2010: https://github.com/blog/626-announcing-svn-support and write via svn since May 4, 2010: https://github.com/blog/644-subversion-write-support

I'm not sure whether to trust that first announcement...

You don't have to trust it, you can go to any gh repository and get the address to the svn access in the sidebar:

> You can clone with HTTPS, SSH, or Subversion.

SVN Devs thought: haha, no one will really believe we would not prefer SVN

rest of the world thought: man, is SVN really so bad that even the devs won't use it? That's sad, but hey, they're responsible developers choosing the best tool for the job.

now that we know it was a joke, are we more convinced that SVN is great?

I would think that people who already thought SVN is great probably continued thinking SVN is great, and people who thought otherwise, continue to think otherwise. I currently have to use both in my job, and look forward to when our conversion to git is complete.

Imo the core of git is superior, but the command line interface of SVN is much better. Git is just horribly messy. The distributed stuff push/pull had a lot of work and improvements, but the work/commit cycle is just messy, at least when compared to SVN or mercurial.

That's fine, I just happen to respectfully disagree :) I started with git though, so I'm sure that has something to do with it. I learned and used git for quite a while before I had to use svn for work, and I found myself very annoyed with certain svn-isms.

If any SVN dev truly believes that svn is better than git in any technical sense then I wouldn't trust the engineering judgment of that developer. However, it's also clear that svn is a hugely important project, not just for legacy reasons but also to provide certain benefits (mostly around simplicity and control) that many organizations need. But SVN itself has none of those needs, it's an open source project of the nature for which git was specifically designed. So I'd think any rational developer would say it's perfectly reasonable for SVN development to use git. All else being equal, of course dogfooding is ideal, but in this case all else is clearly not equal.

    If any SVN dev truly believes that svn is better than Git in any technical sense then
    I wouldn't trust the engineering judgment of that developer.

Hi. Small-time Mercurial contributor and Kiln founder. I use both Git and Mercurial in my daily workflow, and only on very rare occasions touch Subversion.

Subversion is better than Git and Mercurial in at least several key areas:

  1. Access controls.  While this is not necessary for individual products, or even many
     companies, only Subversion offers the kinds of access controls that some large companies
     require.  While you can *work around* that by sharding your code into tons of repositories,
     not all companies want to do that, and I don't honestly blame them.
  2. Very large repositories.  Facebook's work on Mercurial finally allows Mercurial to
     scale to those sizes (with significant trade-offs), but Git still cannot.
  3. Very large files.  Game companies in particular need to do asset management.  Subversion
     can work with large files directly, Mercurial can kind of "fake out" working with them
     directly through largefiles, and Git forces you to use a third-party tool like Git annex
     with a custom workflow.
  4. Interop with legacy tools.  Subversion repositories can be accessed trivially with WebDAV,
     which, while I honestly think is mostly a antifeature, does allow random people in your
     office to trivially access things in Subversion directly via Finder/Gnome/Windows WebDAV
     support (and even commit, with proper settings, simply by saving).

Just because Subversion doesn't use Git's branching system and isn't distributed doesn't mean it's totally without merit, and someone so wrapped up in Git's ecosystem that they can find no merit left in Subversion is a developer who likely has an irrational approach to evaluating systems.

also, you can sync to a subdirectory in SVN - not git.

1) yeah, although I question the sanity of doing this. 2) is this related to #3? 3) yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo. But you are right - putting giant files in git is a terrible idea, especially if you change them often.

> yeah, although I question the sanity of doing this.

the sanity of access control?

> is this related to #3?

Not necessarily.

> yes, but IMO VCS should be used for source files (mostly). large assets should go in an artifact repo

Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?

>the sanity of access control? only at a directory level, git has it at a repo level.

>Great, so now the code and the assets going with the code, both being used to build the product, are completely out of sync and essentially unsyncable?

no. read up on artifact repositories. you declare the asset version that you depend on in your a build script. the assets are fetched from the artifact repo.

there pros and cons of course...

> no. read up on artifact repositories. you declare the asset version that you depend on in your a build script.

Yes, that's "essentially unsyncable" when you have thousands of assets and have to keep them synchronised by hand. It has the same sanity as considering tarballs to be a good version-control scheme.

> there pros and cons of course...

I see no pros compared to a VCS which can handle code and other assets in the same repository and keep them naturally synchronised by virtue of them being naturally synchronised.

you don't sync them by hand. ever heard of ruby gems, maven, gradle, npm? these assets are all versioned and available via http.

these assets can be referenced by many other systems, not just your source repo.

> you don't sync them by hand.

Don't you now? How else is your tool going to know which version of an asset it's supposed to fetch from the asset store without you telling it?

> ever heard of ruby gems, maven, gradle, npm? these assets are all versioned and available via http.

> these assets can be referenced by many other systems, not just your source repo.

Wow, great, now game developers can do something they have absolutely no desire to do, at the small cost of not being able to do what they need. I'm sure they'll be thrilled.

You pointed out a couple additional things I missed, but you also put words in my mouth. I did not say there is "no merit left in Subversion" and indeed explicitly stated that it does have important use cases.

However I stand by my statement on the technical underpinnings. The fact that svn does not distinguish between a repo, a directory, a branch and a tag means that it is ill-defined and is an evolutionary dead-end. Incidentally there are some benefits for things that git does poorly, but that doesn't make it a good architecture.

Agreed here. Also a point on large repositories (most of my work I prefer to do in Mercurial but there are cases where I would prefer SVN). Mercurial at least has only a minor learning curve from SVN, while Git seems to me as if leaky abstraction is the rule. Mercurial also has far better audit control features than Git (it possesses a good superset of functionality here, including two different branching systems, one of which is designed to make it easy to audit long-lived branches).

The big problem with a DVCS is that if you are doing asset control on a lot of binary files is that when someone clones the repository they need to clone all versions of all large binary files. This is a mess. Checking out a revision and working with it is far cleaner. For example, if you are doing a lot of work on, say, PSD files, you probably don't want to use a dvcs generally as it will use needless disk space and network bandwidth for marginal benefit.

As for your 4th point, there are plenty of times I refer people to use wget to get the latest version of a file on svn from a specific branch. This is actually a very nice feature. We are looking at moving LedgerSMB to github and their subversion support makes this decision easier in part for that reason.

SVN has PHP bindings, git doesn't. No matter what you think of PHP or SVN, it's difficult to argue that there is no single use case which wouldn't be affected by this (I myself have recently had to choose SVN for a project for this very reason).

Isn't https://github.com/libgit2/php-git what you're looking for?

you're certainly aware that libgit2 is a reimplementation of git, largely sponsored by github since the original git libraries are binding-unfriendly to say the least. The de-facto ruby "bindings" (grit) were a mere wrapper around cli git and afaik this used to be the only way to go.

I tried to use libgit2 for a project last year and a coworker did a couple of patches and I can say that there's still a lot of ground to cover until libgit2 is at least somewhat feature complete. Back then, clone via SSH and other _must_have_ features were unimplemented.

How unlucky, you must have just missed it. Clone via ssh was added in May last year!

What were the other must-haves that were missing?

Linus uses libgit2 [0] albeit as a data format, not as a basis for VCS.

[0] https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

And surprise! I did not argue that. I wish people would read my comment a bit more carefully.

You said:

"If any SVN dev truly believes that svn is better than git in any technical sense then I wouldn't trust the engineering judgment of that developer."

and I gave one example in which svn 'is better than git in a technical sense'.

Poor choice of words on my part, but when I said "in a technical sense", I meant it's data model and architecture. Bindings are just a feature that can be written at any time, data model and architecture are something that can never be fixed.

More importantly, I specifically alluded to use cases that svn is better than git for. In no way did I ever "argue that there is no single use case which wouldn't be affected by this".

Indeed, I recall the mercurial maintainers discussing a move to git in all seriousness.

What? I don't believe this. Git has nothing that hg devs would want, and lacks many features that hg aficionados like me love. Where did you see this move?

Wish I could find it now, it was linked to on HN between 6 and 12 months ago IIRC, it was on an issue tracker or mailing list archive. A number of the devs were in favor of moving to git, it was shot down but was an interesting discussion and appeared to be serious. Git was a better fit for some particular use case in the workflow on Hg trunk, but now the details have escaped my mind.

It's April 2, no longer cool to be an April fool.

And plausible that a bunch of respected developers could actually be that nasty to each other in a ticket thread.

In which universe would that be plausible. It's not in the one that I live in. The SVN developers were always fairly candid and open about the fact that they think, that SVN is the tool they want to build, but that their priorities do not align with every other project under this sun. That is, unlike Linux, who promotes git as the superior and end-of-it-all VCS, the SVN people publicly state that they're building a system that adopted certain tradeoffs that may make it unsuitable for some kind of project - especially for the linux kernel. [1] Even though I dropped SVN and adopted git for the large majority of my projects, I still see the occasional project that would be served much better by using a stupid, centralized VCS such as SVN and I'm happy that SVN exists and continues to thrive.

[1] http://subversion.tigris.org/subversion-linus.html

Another very April fools this year is the one of the Gallium Inria team (the one behind the OCaml programming language): they released a French version of OCaml. What's awesome is that the provided source actually compile to the described compiler!

See http://gallium.inria.fr/blog/ocaml-5/

Where does it say anywhere on that page that it went wrong? How did you come up with this headline? As far as I can see, it went perfect in every way.

You kidding me? Is this how April Fool's are supposed to go!? If it is, I am quitting the internet on April Fool's.

What's the problem? Did you read the last post? Most parties "complaining" about the move to git in the ticket were actually aware it was a joke:

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

Since almost everyone on the JIRA knew it was a joke, what were the negative consequences that affected you so deeply?

The main point of April Fools is that you fool a lot of people. It's more or less in the name. Of course one should put some thought into possible consequences, but I think this one was quite harmless. (Gullible people becoming angry/shocked/etc. is considered harmless.)

Yes. Absolute perfection. Loved it.

The headline here is misleading. It didn't go wrong. That was the intended effect. I thought it was brilliant!

I wonder how many people were like me and completely missed the point of the HN post yesterday.

I thought Apache was saying they were moving all their projects to git from svn. I didn't realize svn itself was an Apache project.

Projects are allowed to use Git instead of Subversion, and there's a workflow in place, as noted in the ticket. Many projects have moved, and many haven't. They seem fairly undogmatic in that aspect.

still i think you would expect the svn project would use svn :D otherwise it's a pretty treacherous admission of a codebase being legacy only

This is what I thought as well. This seems like a really poor joke. A press release describing such a planned move that praised git and slammed subversion might have been funny. By an actual JIRA ticket is inappropriate.

Why is that inappropriate, out of curiosity?

I originally thought the same thing, until I read through to the article.

Git is already supported by many Apache projects, though. The Apache Flex team did the move quite a while ago, so their primary repository is in Git.

This is the first april 1st gag I've respected in years. Bringing Jaglieski (ASF co-founder) in as an evil PHB was inspired.

No doubt, this was the #1 joke for April Fools 2014 as far as I'm concerned.

To be honest it would make perfectly sense to host a VCS on another VCS, it's not about religion wars, pride and protecting your offspring. VCS have different features and some teams might be better off by using SVN, while the team developing SVN might be better off by using git to develop in a distributed manner.

I understand the need of self-hosting/dogfooding/whatever, so it wouldn't probably be a good idea, but it's not something to flatly dismiss just out of principle.

Yeah, I think dogfooding is the only reason they should still use SVN. However, it's such an important reason that they should not switch to anything else.

I also literally know no SCM, ever, that was not maintained on itself, except insofar as we might be able to have an epistemological discussion about early versions of CVS v. RCS. Bitkeeper, Mercurial, Git, Subversion, Perforce, tla, Monticello, Bazaar, darcs, Fossil, Monotone, and TFS are all maintained on their own systems. Subversion maintaining itself on Git would not exactly be a vote of confidence for me.

It would at least give you a lot of confidence that the decision-makers understand that there are differences between various SCMs and that there isn't a 'one-size-fits-all' solution.

Was SourceSafe maintained on itself?

No, but that wasn't an SCM. ;-)

More seriously, I believe that SourceSafe was maintained on Microsoft's fork of Perforce, but I don't honestly know, nor do I have contacts at this point who'd be able to find out.

I would surmise that the original authors at One Tree did maintain it on itself, but it's a pity that it's nigh impossible to find any sources on this.

There are a couple of SCCS projects which are just barely outside of your epistemological discussion. ;)

CSSC, which is the GNU project's implementation of SCCS. It uses git: http://www.gnu.org/software/cssc/ . CSSC is meant as a stepping stone to migrate existing SCCS projects to some other version control system.

Sun released SCCS in 2006. A couple of forks exist. One is the Heirloom project. If I read http://heirloom.sourceforge.net/devtools.html correctly, they maintain their version of SCCS using CVS.

These are unlikely to affect your vote.

This was my first thought too - it would be a bit like saying you shouldn't right the compiler for one programming language in another, which would be patently absurd.

The other thing I would fear is if there's a bug that somehow prevents people from committing, if the SVN team is using SVN, the bug may get in the way of it's own fix. Pretty unlikely, but still - if my software was the platform for it's own bug fixes, I'd be looking for some more diversity in my stack.

You're assuming that the svn running on the source control server is always the top of tree. I would assume that they use the latest stable release, not the latest checkin. And even if they did run into a problem like this, they could always downgrade the version of svn on the server, so long as it doesn't include a breaking repository format change.

From the InfoQ article yesterday: "Although posted on April 1, the switch is not an April fool." (http://www.infoq.com/news/2014/04/svn-migrates-to-git)

The whole thing was clever, but I'm not sure it counts as as being "fooled" when the gag specifically denies being a gag. I'm not sure I like this precedent (and I love April Fools jokes in general).

But maybe the article from yesterday was a third-party source who had fallen for it? If that's the case, then well-played. :)

I wondered for a second "Is CVS still hosted using CVS?" only to discover that the answer is yes and that all is still right in the universe.

Imagine if nobody had it installed, it would be lost forever. Or until someone rebuilt it from the spec.

Couldn't you just find any old package and install that?

I think the point is that the old packages will fail to install on future computers.

Oh, right.

Adding to the collection of people supporting this as - finally - an awesome April Fools joke. I give them a 10/10 on conception and execution! Remember the reaction to the initial radio broadcast of War of the Worlds (yes, not a 4/1 event, but as close of a parallel situation that I can recall).

Bravo, Apache, nicely done.

The sad thing is that this would be a welcome move, especially the idea of making svn a transparent UI on top of git as a repository backend. Given that github already supports using svn to check out its repositories, generalizing that seems quite sensible.

I'm a little bit confused as to what is going on here. There was a vote to migrate the svn project to git. Did it pass legitimately or as a joke? Is it actually going to happen now? Why is it gone wrong? Why does everybody say it's actually gone right? Why does everybody say that this is a rare example of a good April Fools joke?

I believe there was no vote

They spent the whole day (12+ hours) viciously debating the move from svn to git, but in the end it was all a joke. That's dedication.

There was no vote, and it's not going to happen.

Ok, so "vote passed" is part of the joke, and just the beginning of the argument.

Wait, so as a joke, they put it up to a vote to migrate SVN over to Git, and it passed? Now, they have to actually do the migration now?

No, they never voted but a few people said they did in a private meeting as a joke. The entire thing was a joke and they'll stay on SVN.

This was the only April Fools gag that I even chuckled at this year. Good stuff :)

It did not go wrong which just made this link confusing and not funny.

It was funny to see the bureaucracy get into the act. I had a good laugh.

I almost fell for this one:

Sublime Text 3 Stable is approaching http://www.sublimetext.com/forum/viewtopic.php?f=2&t=15741

OK damn. I totally fell for this yesterday. Mentioned it to a few colleagues... The thing is, it makes such good sense! :-)

Actually, I thought it made a lot of sense for the project. Subversion still has a place for large-file/binary repos

Well it was a good idea/Bad joke.

Gone wrong? It was perfect!

Headline should read: "Apache SVN project to migrate to git after April fools joke gone wrong". This removes the way I read the headline; that the Apache web server was moving from SVN to git. Which doesn't seem funny at all :-D

No, the Apache SVN project is not to migrate to git. The prank was that the Apache SVN project was to migrate to git; it is now not.

I'm still confused, are the hosting it on git or not?

Give em an excuse to really switch to git and they'll GLADLY do it! :)

It is probably a bad sign for the project's culture that people acting like assholes towards each other gave it an air of legitimacy.

Risky to make jokes with plausible things and especially without a hint.

Stackoverflow did it better in my opinion (lots of hints): https://news.ycombinator.com/item?id=7507830

Completely disagree.

The best April Fools jokes are ones that are actually plausible. Bonus points for being controversial as well.

True, this is the most amazing one I can remember.

Totally.

Without some degree of plausiblity it's not an April Fools joke.

I'd say of you have to give hints for a joke then the joke's not good.

These April Fools need to stop. It was funny and unique a few years ago.

Now it is just used as a vapid, contrived marketing exercise.

Most are marketing exercises, this one is pretty clearly just people having fun.

not funny!

Humour is subjective.

I'm surprised this comment got hammered so badly given that, to judge by the data I see, more of the community agrees with it than disagrees. I bet it was because the only people reading this post (which I buried) are the ones who are interested in it.

Reply on news.ycombinator.com