
It’s time to stop using Subversion - fogus
http://altdevblogaday.org/2011/03/09/its-time-to-stop-using-subversion/
======
selectnull
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".

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

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

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

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

~~~
dustingetz
well obviously, but the point is in a vaccuum, git as a tool appears to be
superior in every way that matters.

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

~~~
dustingetz
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. ;)

------
abyssknight
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. ;)

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

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

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

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

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

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

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

~~~
hollerith
Not if he put equal amounts of effort into learning git, svn and hg.

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

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

~~~
jshen
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)

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

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

~~~
nupark
_... 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?

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

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

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

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

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

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

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

------
mcantor
> _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.

~~~
kabdib
> (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.

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

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

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

~~~
MindTwister
How about TortoiseGit? <http://code.google.com/p/tortoisegit/>

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

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

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

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

~~~
jmillikin
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".

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

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

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

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

------
Aegean
Very old news.

~~~
spacemanaki
And yet some of us are stuck using CVS.

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

~~~
selectnull
"someone always has it worse."

Unfortunatelly, not in your case. ;)

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

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

------
binarysoul
a simpler solution, use git-svn

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

