It's time to stop using Subversion - <AUTHOR> http://altdevblogaday.org/2011/03/09/its-time-to-stop-using-subversion/ <comment><USER2> I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it.

I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it".

<comment> loup-vaillant > _They all have [their] merits_

 _That_ is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine".

It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oops"² in exchange for new powers. We sometimes even actively try to deny others the very powers we refused to take.

Here, you were very close to make that mistake about svn vs Git/Hg/Darcs. Git doesn't dominates svn yet, but I'm sure it will. Then, subversion _will_ deserve "you should stop using it".

But most often, this mistake is made with programming languages (it's a variation on the blub paradox). And the effects are far worse there.

[1]: <http://wiki.lesswrong.com/wiki/Fallacy_of_gray>

[2]:<http://wiki.lesswrong.com/wiki/Oops>

<comment><USER3> But SVN really is fine. And Git definitely isn't better than SVN in "every way for every foreseeable usage."

 _> We sometimes even actively try to deny others the very powers we refused to take._

Huh? Who was that directed at?

<comment><USER4> I'd love to read a post where someone decided SVN is superior for their purpose, and their stance is defensible. I can't think of any reasonable use cases.

<comment><USER3> I'm not personally a big SVN defender/apologist, but I'll bite.

Imagine you're on a small team developing closed source software. Like many people, you already have SVN, your team already knows SVN, it's already integrated into build system and you're using Trac for ticketing. Based just on that, I would absolutely keep using SVN instead of transitioning to Git. Perhaps you disagree, but I hope you'll at least concede that's a reasonable position.

<comment><USER4> well obviously, but the point is in a vaccuum, git as a tool appears to be superior in every way that matters.

<comment><USER5> Most people neither live nor work in a vacuum.

You come from the "ya, well..." camp it would seem? Supremely confident that your choices are _the_ correct way to do things, but when someone points out a valid difference, your answer begins with "Ya, well...". I see this all the time from brash young superstars.

<comment><USER4> ya, well, factors external to the merits of the two tools is irrelevant to the question I intended to pose. My question could have been worded better, sorry for the confusion. loup-vaillant's explanation is clearer. ;)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> How about, no? The day you realize the tools you use are not the most important part of your function is the day you finally understand what it is you do. Yes, tools can make things easier, run more smoothly, or make you _happy_ but... Can you do the same, if not better, job with alternate, less efficient tools? Yes. Tool elitism is no better than language elitism.

Now, I'll be in the corner using notepad and copying my file every time I make a major change. ;)

<comment><USER7> > Can you do the same, if not better, job with alternate, less efficient > tools?

The question is: Is a tool just 10% more efficient or does it introduce a whole new _quality_ of working with it?

What do you do when your already delivered software has a bug that needs to be fixed urgently, but you already started to add new features that are not ready yet?

Using branches with svn is a thing just everyone is _scared_ of (and rightly so), but with git, this has lost it's horror. You can _confidently_ handle the above situation with git. That's a new quality.

<comment><USER8> I don't understand the branching mantra that I hear from git proponents. Subversion has had merge tracking since 1.5, and with it, branching and method is as painless as it can reasonably be.

Unless you want to work on a submarine, or have an organizational need for people to maintain private unpublished branches (eg, open source), I don't really see what advantages git has to offer over subversion in organizational (read: corporate) development.

<comment><USER7> Well, in my case it's not a submarine, but a train.

And yes, it is great advantage that I can freely make a branch with the new feature that I just started working on, without having to summon a meeting to let everyone know that a new branch will be created, which is not intended to be used by anyone else even if it's visible to everyone.

<comment><USER8> I don't follow. Isn't needing a meeting to create a branch an _organizational_ problem, not a technical one?

As for working offline, my choice of the submarine example was intentional. 10 years ago I used cvsup (and later, svk) to work on the train and plane while using cvs and svn. That mode of working predates git quite a bit, but it's also much less useful nowadays -- Now I just use phone tethering and inflight wifi. I'd be working less efficiently without Internet resources at hand, so now that wireless technology has caught up, I don't have to.

</comment></comment></comment></comment></comment><comment><USER9> Do not confuse elitism with minimalism.

Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard).

When branching in git is a simple _git checkout -b newbranch_ away as opposed to _svn copy<http://repo.com/some/path/to/trunk> <http://repo.com/some/path/to/branches/somenewbranch> _ \- then what else is there to say, really?

Sure, svn is extremely easy to setup and use in small teams. But it is simply not geared towards modern development flows.

I appreciate tools that appreciate my time (and sanity) as a developer. And git does just that.

<comment><USER10> > Git is simply easier to use, and harder to shoot yourself in the foot with - > at least when it comes to the basic flows. (Granted, you can blow your face > off with git if you really try hard).

I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git _I had instances where the repo was so wedged I had to just torch .git and start over. I know more now and can get out of it, but with Subversion I've_ never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users.

<comment><USER11> It sounds like you were training people on git when you didn't know git very well. That's an odd way to judge git.

<comment><USER12> Not if he put equal amounts of effort into learning git, svn and hg.

<comment><USER11> If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.

<comment><USER8> What do you mean by 'sane', and how does subversion (which includes merge tracking) fail to meet your definition?

<comment><USER11> It's not a DAG. Since you know that subversion has merge tracking since 1.5 I'm going to assume you know what I mean. I don't have time or space in a comment to explain why this is so much better. For an example or two: [http://stackoverflow.com/questions/2613525/what-makes- mergin...](http://stackoverflow.com/questions/2613525/what-makes-merging-in- dvcs-easy)

[http://stackoverflow.com/questions/2475831/merging-hg-git- vs...](http://stackoverflow.com/questions/2475831/merging-hg-git-vs- svn/2486662#2486662)

<comment><USER8> _I don't have time or space in a comment to explain why this is so much better._

Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution.

YMMV, but I don't think it's as clear cut as you make it out to be.

<comment><USER11> Let's assume it isn't as clear cut as you say. That still leaves the question, why use an inferior tool? The argument that programmers are too dumb to reason about the distributed nature of a dvcs isn't a good argument to me. It took me one weekend with the pro git book for me to understand git well. That's a small price to pay for a superior tool.

<comment><USER8> _... That still leaves the question, why use an inferior tool?_

This assumes that git has no significant practical drawbacks that might outweigh the constrained value of its merging support.

A bad car analogy: I never drive in the winter. I commute 1 hour each day to work. I have the choice between:

\- A large SUV that gets 15 mpg but has traction control for handling icy winter roads and 16000 lbs of towing capacity

or

\- A 30 mpg commuter car.

If we assume that subversion merging works fine (which, in large organizations, is my experience), then the next question is -- what feature(s), exactly warrants git's additional complexity? Why, in our organization, would we want to encourage people to create out-of-sight branches? What is the actual advantage to having individuals care about n-way merges?

<comment><USER11> Subversion merging does not work fine. I guess you didn't read my links, so I won't spend more time on this.

<comment><USER8> I read your links. I also use subversion merging every day while maintaing feature and maintenance branches. It works fine and involves significantly less complexity than git.

<comment><USER11> I use git everyday. I don't know what this complexity is you speak of. It took me a weekend to learn git, and about the same for subversion, but git gives me more flexibility and power.

<comment><USER8> Flexibility and power come with complexity, and in his case, provide no practical benefits to most organizations. I use git regularly when interacting with open source projects, but don't see the value in it's added complexity and decentralization in corporate environments.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> As someone who got started in this field about 10 years ago, I find the mass- adoption of and then mass-exodus from subversion fascinating. I remember sitting in the audience for a talk by Greg Stein introducing subversion at ApacheCon ('02 maybe) and being wow'ed.

I'm trying to think if there's another piece of architecture our industry has both so universally embraced & discarded (hyperbole, I know) in the last decade.

<comment><USER14> It's because 10 years ago there weren't really any distributed version control systems, and the original aim of Subversion was to fix everything that was horribly broken in CVS. They definitely succeded with that design goal, but since they're stuck in a centralized design, there's nothing they can do to move it to a distributed model, and it's not something that could have been foreseen 10 years ago.

They're simply the last technology before a paradigm shift, and that's never a good position to be in.

<comment><USER2> I think that's the best position (in case of svn) to be in.

Subversion is, imho, the best of centralized scm-s. There are many companies that, for some reason or other, will not switch to dvcs. It really doesn't matter that distributed model is better than centralized, some people will not switch over. And svn is great choice for them.

</comment></comment></comment><comment><USER15> > _If_ I'm committing some large assets...

(Isn't version control _mostly_ for text files?)

> _If,_ while the upload's been happening, I've made more changes to my > working copy...

(So you're uploading a large--presumably binary--file, and you're continuing to work on it while it's committing...)

> I have to carefully pick out my new changes and keep them separate from my > old changes.

(Wait, what? In a binary file? Or did you commit the binary file _and_ changes to smaller text files in the same changeset? If so, you should be committing them separately. Either you're making small commits to text files that commit almost instantly, or you're making large commits to binary files that you can't "pick out" changes from anyway. Gotta pick one.)

> As soon as the commit is published, other people _may_ check it out and try > building it...

> ... _if_ I can't access the repository server – _if_ it's gone down, or _if_ > I'm working remotely – then I can't commit at all.

> ... but there are _many reports_ [ _weasel words_ ] of it being _somewhat_ > prone to error. _If_ your mergeinfo property has been corrupted _somehow_ , > it _might_ be extremely hard to spot...

I see a lot of inconclusive beating around the bush here. The author doesn't want to come out and say that any of these are concrete showstoppers because they are all, at worst, edge cases that experienced svn users mostly know how to deal with anyway. Every VCS has its own bugbears like these, git included.

I have been using subversion for years; I do all kinds of insane nonsense with private branches, merging and merge-tracking, large asset commits and all of the things this article uses for its doomsaying. I run into big problems _maybe_ two or three times a year.

The writer suggests that git is better.

For some reason, even though I have read numerous manuals and guides about git, and have grilled git experts, and have regularly used git myself, and presumably understand how it works, I have to go on a farcical journey into its implementation details _every time I do ANYTHING_. I always end up in #git, or calling a more git-savvy friend. Everyone inevitably has a different answer that involves a lot of shrugging and "Oh, I guess _this_ actually happened." This was the result even when _all I did was follow the instructions at help.github.com/forking, TO THE LETTER_.

Perhaps I am just a moron, and subversion is just VCS for morons. If so, I am too far gone to realize.

<comment><USER16> > (Isn't version control mostly for text files?)

No. For long-life projects I snapshot entire build systems (toolsets, documentation, you name it) so that a precise image can be re-created later.

<comment><USER17> Real world requirements intrude:

Years ago, in our 100+ coder company I kept finding copies of Microsoft's Developer CDs in CVS. Everything to set up a build machine was in there.

Furthermore, because developers sometimes didn't all have the same build environments, all of the intermediate builds were also checked in since you couldn't assume your machine would build exactly the same executable code as anyone else's machine.

CVS was definitely not built for this, but it worked. And if it works, and a programmer thinks it solves his problem, it will be used.

I discovered this because we kept getting problems with orphaned CVS locks, and people complaining of the slow checkins (CVS did the diff on the server, so upload the slow way over your ADSL line all those giant files that didn't change.) Which led to the day I typo'd a lock removal command and deleted all files with "rfl" in their name. Not a common sequence, unless your software deals with "overfly"s. Hurray for backups!

</comment></comment></comment><comment><USER18> Also: .gitignore is fundamentally saner than svn:ignore properties. You can commit it, or not. You can add to it locally without adding it into your next commit. You can make it ignore itself. It applies recursively.

</comment><comment><USER19> Having just spent the last month converting our operation to Git here at work, I can tell you the main force in keeping Subversion around are Windows users who are used to TortoiseSVN. There _still_ is no viable Git UI for Windows (or any other OS, really -- but Windows is especially immature) and the people who make decisions a) use Windows and b) "don't have time" to learn git on the command line.

<comment><USER20> How about TortoiseGit? <http://code.google.com/p/tortoisegit/>

<comment><USER21> I tried it a few months ago. I created a new repo and tried to add a file. It gave me an error. So I tried a different way of adding a file. It crashed hard.

TortoiseHg for Mercurial, on the other hand, is a pleasure to work with, especially the 2.0 release that just came out.

</comment></comment></comment><comment><USER22> Why do some devs not like CLIs? GUIs are nice sometimes but I definitely don't pick my tools based on which has the nicest.

Also, it's not like SVN is suddenly bad or anything. I prefer GIT but I'm not tripping all over myself to switch over all of my existing projects.

<comment><USER23> CLIs are nice once you remember commands to use them and usually devs have more important things to do than to learn another set of commands.

</comment></comment><comment><USER24> The large binary file thing keeps coming up again and again.

I hear mercurial is working on support for these, but to my knowledge it's not something Git is overly concerned by.

I keep seeing statements like "If you're storing large binary files in version control you're doing it wrong", which leaves me wondering - what's the generally accepted approach for versioning artwork. I'm mainly thinking about source formats like PSD or fireworks PNGs.

<comment><USER25> PSD and PNG files are not usually counted as "large". When someone says "don't version large binary files", what they mean is "don't check in a DVD ISO of Fedora".

<comment><USER24> They may not suffer from the efficiency problems, but diffs and merges are still problematic. Is there any VCS tool designed to handle these sorts of things?

</comment></comment></comment><comment><USER26> The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. With svn, it would be easier for the hardware to be redundant and backed- up.

<comment><USER27> I fail to see your point. Every copy of a git repo is a _full_ copy [1] - unlike a svn checkout. If you follow a centralized server model with git you have a copy on the server and every workstation it is checked out on. With svn, the full repo only exists on the server. Why couldn't you have a redundant, backed up central git server?

[1] Not a substitute for real backups of your repo!

<comment><USER26> Whenever people talk about git, they seem to talk about how you can have all of these working copies locally. My concern is the frequency with which code would be published to the centralized server and possible loss if all of the working copies were to disappear.

Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.

</comment></comment></comment><comment><USER28> Very old news.

<comment><USER29> And yet some of us are stuck using CVS.

<comment><USER30> Some of us are stuck using Clear Case or Visual Source Safe. Whatever source control you're using, someone always has it worse.

<comment><USER2> "someone always has it worse."

Unfortunatelly, not in your case. ;)

<comment><USER28> What was the name of that version control tool before CVS, RVCS? Back in 2007 I had heard one very big name hardware company using that for version control and planning to move to CVS as they thought the former was beginning to show its age.

<comment><USER26> Or you could talk to Joe down the hall. He has the 'gold' version of the source code on his desktop. Don't forget to send him your changes when you are done and he will integrate it to the current 'gold' version.

</comment></comment></comment></comment></comment></comment><comment><USER31> a simpler solution, use git-svn

<comment><USER32> Any time I take on a client project that uses SVN, I _always_ use git-svn. Once you get used to working with git-flow and feature branches, you never go back.</comment></comment>