I belong to a rare breed of programmers: I was born and raised on Git. It’s the only version-control system that I’ve ever used. This is my personal story of how I had to use SVN temporarily for a contract project.
Now, I know there are a million of blog posts out there saying “Ooh, look how much better Git is than SVN!” I’m not trying to tell people something they don’t already know about Git, SVN, and the difference between them— I’ll just be telling my own personal story and my own impressions of SVN.
I started my programming comeback about 3 years ago. When I was a child, I programmed a lot— I was taught Basic in third grade, and I spent a lot of time of my elementary school and junior high making various little programs in C and Pascal. But I took a long hiatus from programming starting at about 10th grade, because I was frustrated with how many stupid technical details were involved in programming.
That hiatus ended about 3 years ago as I started learning Python, programming computer simulations for my Physics research, and about a year after that became a professional programmer. By the way, the main reason I chose Python is because Paul Graham mentioned it favorably in one of his essays.
How did I start out with version control? I saw the term “GitHub” being thrown around a lot on Hacker News. It seemed to be something everyone liked, so I figured I’ll try putting my project GarlicSim there. I learned Git. It took a while, because I was still not very technical, but eventually I got the hang of it enough to work in a single branch.
After a while, I understood what branches meant. I understood that I was able to create alternate versions of my code, work on them as much as I want, and decide at my leisure whether they should be merged into
master and become an official part of my project.
I was happy. Branches are awesome.
At some point I heard about SVN. I heard that it was something like a predecessor to Git.
What I imagined in my mind was that SVN was to Git what Windows 98 was to Windows XP. I imagined that SVN was just a crappier version of Git. Like, same idea, same workflow, just with more annoyances and less polish.
That perception changed when I got my first programming job.
Then I started programming professionally. I was hired by an Israeli startup to work on a Django project. I was kinda surprised to learn that they were using SVN. I figured that a technology startup would, you know, care about technology. But I said, “Meh, so I’ll just have to use Windows 98 for a while instead of XP, I could live with that.”
So I was just about to learn SVN. This is a dramatization of the conversation I had with that company’s chief developer: (I ask you to read the text in italics in John Cleese’s famous surprised voice.)
Me: Hey man, I wanna make a small change to the code to add [Feature X], I’ll just make a little branch, alright?
Chief developer: What?! You’re gonna make a branch?!
Me (taken back): Eh, yeah, a branch. So, you know, I could make changes in it without affecting our
trunk, or whatever?
Chief developer: And how are we supposed to put the changes back into our
Me (totally freaked out at this point): Eh, merge them back?
Chief developer: Merge? MERGE?! That’s a mighty big word for someone your size!
And then followed a conversation in which he explained to me that branching-n-merging in SVN is really fucking complicated. I don’t remember exactly what he said was required, but it changed my perception of SVN from:
"SVN is a slightly crappier version of Git."
"SVN is a version of Git in which every time you want to start a branch or merge it back, you have to sacrifice a young virgin to the source-control gods."
I was not happy.
Luckily, the chief developer was considerate of me, and the company was small enough (only a handful of people), so he agreed that we’ll just move our entire product to Git.
I was saved at last moment from the atrocities of SVN.
Recently I got a nice contract job. And, like any other contract job after my initial trauma with SVN, I made sure to ask that the job was in Git before I started the job. Unfortunately, despite being told that the job was in Git, it turned out that the job was in SVN, and that we’d move to Git “after the deadline.”
I was not happy. It turned out that I had to learn SVN after all.
I had my brother give me a crash course on SVN via phone. My brother’s a C++/Java programmer, and he had to use SVN for a while, so he agreed to help me with it. He has experience with Git so he was in a good position to explain the differences between the two. I primarily remember him explaining to me about branches.
Now, I remember seeing the “branches” folder in the SVN repo. I thought it was pretty weird to keep branches in a folder, but whatever. I assumed that the stuff in the “branches” folder was like the stuff in the “.git” folder in Git: Magic data that contains all your branches and allows you to switch to them at will.
Then my brother explained to me that this is not the case. I remember this part of our phone conversation pretty well, because at that point I was sitting on my knees on the carpet, with my head in my hands, looking down into the seat of my office chair. He explained that SVN doesn’t really have branches, it’s just a folder called “branches” that you manually copy your code into.
I was not happy.
Though, on the other hand, it was kind of a relief; it was relieving to know that SVN doesn’t even try to do branches. Because God knows how badly they would fuck it up if they would have tried to. Copy-pasting folders is major bullshit, but at the very least it’s predictable; when you use
cp, you know exactly what you’re getting, which is something you can’t say about
That partial relief nonwithstanding, the whole “branches” thing in SVN is utterly ridiculous. In the past when people told me “SVN has branches too!” I knew that something wasn’t right and I just assumed that SVN branches suck, but now with this new knowledge I can answer in confidence, “No, SVN does not have branches, it merely has a folder called “branches”, which is a far cry from having actual branches.”
You know what SVN’s “branches” folder is like? It’s like taking an A4 paper from your printer, drawing a Flux Capacitor on it, hanging it in your car and declaring with a satisfied grin, “My car’s a DeLorean time machine! I can go back in time!”
One other thing I had to deal with in SVN was doing “SVN ignore” (I don’t know the SVN jargon for it.) Basically I was looking for the SVN equivalent of
.gitignore: A list of file patterns that do not get source-controlled, ever. This is very useful for build products, files containing passwords, user-uploaded static content, etc.
Now in Git, you just have a file called
.gitignore in the root of your repo, and in that file you write the file patterns that should be git-ignored, like
build. You save the file, and that’s it. I assumed that there would be a similar mechanism in SVN.
You can probably guess where this is going by now.
It turned out that SVN’s ignoring mechanism is far more complicated than that. It basically holds a list of SVN-ignored file for every, single, folder in your repo, and there is no convenient way to edit all these rules for the enitre repo, or even just view them. You have to run this baffling command in order to even view the ignore rules. Also, when you edit the ignore rules for a folder, you’re not just editing a text file like in Git, you have to actually set the rules using
svn. I tried actually going into the dreaded
.svn folder and edit the text file that holds the ignore rules myself, but it was encoded in a really stupid encoding, and in order to write rules there manually I would have had to count the number of characters in my ruleset and type it as part of the text file.
Eventually my new client saw how bad of an effect SVN was having on me, and he let me move us to Git. So over the weekend I used svn2git to convert our repo to Git and now we manage all our code in Git. Uninstalling TortoiseSVN from my machine was quite a happy moment.
Goodbye SVN, may we never meet again.