
April Fools: migrate Apache Subversion project over to the git repo - yuvadam
https://issues.apache.org/jira/browse/INFRA-7524?aprilfools
======
smtddr
_" 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](https://news.ycombinator.com/item?id=7507297)

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

~~~
eik3_de
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?

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

~~~
gecko

        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.

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

~~~
masklinn
> 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?

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

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

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

~~~
masklinn
> 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_.

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

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

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

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

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

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

~~~
fat0wl
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

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

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

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

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

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

------
haberman
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](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. :)

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

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

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

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

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

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

------
orblivion
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?

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

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

------
ethnt
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?

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

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

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

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

------
dsego
I almost fell for this one:

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

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

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

------
callesgg
Well it was a good idea/Bad joke.

------
chatman
Gone wrong? It was perfect!

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

~~~
vertex-four
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.

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

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

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

------
yiedyie
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](https://news.ycombinator.com/item?id=7507830)

~~~
smtddr
Completely disagree.

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

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

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

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

~~~
nashashmi
not funny!

~~~
Kudos
Humour is subjective.

