

Why Subversion does not suck - asinglenet
http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx
The Subversion Sucks meme is popular on the Internet.  However, if we imagine a world without Subversion and other centralized version control systems, it's easy to see why Subversion does not suck, is not fading away, and in fact, has a rapidly growing user base.
======
mtoledo
Curious, we use assembla on our team and our designer uses git (assembla's
git) without any problems.

It's great if people want to have the choice for subversion, tho. Some people
just prefer the tools they are used to instead of learning new, more powerful
ones. But to use that as argument that svn doesn't suck is not a very strong
point.

~~~
mtoledo
Though, when I showed him the article, he agreed with it.. so maybe he's
right. :-D

------
jonursenbach
Here's an idea. Instead of throwing around "Subversion sux", "Git is the new
hotness", how about we all just use what works for us and the projects we're
working on.

~~~
atlei
Agree ! Having gone from nothing to Subversion, I think Subversion is great
(with TortoiseSVN, at least).

Are there better tools ? Is Git better ? Maybe, but different tools for
different uses. For me personally, Subversion does not suck, and I don't need
a "better" tool.

It works, and gets the job done for me !

------
globalrev
All I know is is that Git i supereasy to use for a beginner for 1-man-projects
if you get the right help or tutorial. Preferrably start a repo at github and
you will be waled through how to create a repo(not that there is much to it).

git init git add . git commit -m "blah" git push origin master

git branch name git checkout

easy-peasy

------
scott_s
The author sets up a false dichotomy: Subersion or git. But those are two
different models of source control: centralized and distributed. If you want
to use centralized source control, the choice is more likely to be cvs or
Subversion.

The popular notion isn't that Subversion sucks, but that it's pointless. The
claim I hear is that it's a reinvention of cvs, but it doesn't actually
improve much. Personally, I had to learn cvs, it's simple enough for my needs,
and I see no reason to switch to something that's fundamentally the same
thing.

I think most cvs users are in a similar situation as me. We know Subversion is
better, but those benefits seem marginal and not worth the effort to switch.

~~~
ConradHex
Subversion, in my experience, is worth the effort of switching from cvs. It's
a breeze to set up, and it's a lot cleaner than cvs.

~~~
mpk
I have a lot to say about version control, but I won't get into the details
here.

However, on the 'switch from CVS to SVN', I'll comment and say that SVN is far
superior to CVS.

The whole 'changes committed to the repo up the entire repo version' alone
make this worthwhile.

SVN is also less arcane in its usage.

SVN has better tools for, well, everything.

SVN integrates well with all major IDEs (mine being VIM, but also Monodevelop
and Eclipse).

The switch from CVS to SVN also made our releases much easier to manage
(merging branches is fairly trivial and tagging is a no-brainer).

If you're using CVS in a company, do yourself a favour and switch to SVN. The
basic concepts are the same, so re-educating developers takes all of 5
minutes.

------
mhartl
Branching and merging suck in Subversion. Offline commits suck in Subversion.
Does that mean Subversion sucks? Depends on whether you want good branching
and merging and offline commits. I do; therefore, for me, Subversion sucks.
QED.

~~~
thorax
For what it's worth, they've improved branching and merging (on the backend)
not long ago. Of course it's not inherent to the platform like most DVCS.

------
tome
In a world without Subversion, Subversion would be built out of Git. In a
world without Git, Monotone, Darcs etc. ... well that's where we were 5 years
ago, and it sucked.

~~~
axod
Did it really suck? I was using subversion in a team of around 15, 5 years
ago, and all in all it worked pretty well. It was rare that there would be any
issue or that subversion got in the way.

Maybe git is better... maybe it doesn't matter enough to bother changing. But
you have to admit these types of things are more about what is "in fashion"
than what is better suited to a particular task.

Things go in big cycles. For a few years centralization is excellent, offers
massive benefits, then suddenly distributed is excellent offers massive
benefits etc etc As the post hinted, I wouldn't be surprised if 5 years from
now git is pronounced as a terrible idea, and the trend setters go back to
something more like svn.

~~~
tome
It sucked because we didn't have the possibility of distributed version
control, even if we really wanted it.

Some people and some projects prefer centralized. That's fine. But you can't
build a distributed version control system out of a centralized one.

~~~
kragen
svk? Also BitKeeper was built on SCCS, and ClearCase MultiSite was built on
ClearCase.

------
biohacker42
This is a terrible argument.

Easy when it comes at the cost of features is another way to say it's OK to be
ignorant.

It's one thing to make things as easy as they can be.

It's one thing to not complicate things unnecessarily.

But it's a whole'nother thing to make things easy at the cost of features and
power.

Anyone can make _anything_ easy if they are allowed to cut enough features.

~~~
silentbicycle
Is declining to use something significantly complicated by features you know
you will _never_ need ignorant?

------
bayareaguy
For the stuff I do I find both svn and git get the job done. The only thing
that I regularly experience that sucks about svn compared to git is the speed
of checking out a working copy. Even when using tiny local file://
repositories svn checkouts on my OSX laptop often take several seconds where
similar git operations are instantaneous.

------
blasdel
Subversion isn't even better than CVS across the board: it's slower, wastes a
lot of space, is way less stable, and doesn't have independent
implementations.

------
moonpolysoft
"Even designers can use it."

Why does everyone assume that designers are stupid luddites who can't wrap
their heads around complex systems? UI design is full of nuance and
complexity. It's insulting to designers to assume they cannot deal with DVCS.

~~~
mechanical_fish
Amen.

Meanwhile: To claim that SVN is intrinsically easier to understand than DVCS
is to be very shortsighted. Subversion is a more mature technology: It's eight
years old, and is conceptually based on CVS, which goes back to the eighties.
DVCS is all of eleven years old in its _eldest_ incarnation (according to
Wikipedia) and the current generation of tools (git, Bazaar, Mercurial) date
back only to 2005.

DVCS is a maturing technology. One of the things that happens as a technology
matures is that people learn better ways to explain it to new users, build
better interfaces, build better infrastructure.

If you don't think that DVCS makes enough sense to non-geeks yet... give it
time.

~~~
scott_s
I understand your point about maturing technology, but distributed _anything_
is usually hard for people to wrap their heads around the first time.

~~~
mechanical_fish
_distributed anything is usually hard for people to wrap their heads around
the first time._

I don't think that's necessarily so. Have you ever tried to get an office full
of people to collaboratively author a Word document? What's their instinctive
behavior? They all grab copies. Then each of them hacks away on their copies.
Sometimes two or three of them email their hacked copies to each other and
mash them up, using cut and paste. Eventually some poor SOB has to get
everyone to email over their individual versions so he can merge them.
Hopefully they've all been using Track Changes (which is, in a sense, a poor
man's facsimile of a single-document DVCS!); otherwise it's an even bigger
clusterfuck.

That's a distributed model. Ever since the invention of photocopiers and email
attachments, people have had to develop a very good understanding of how that
model works, and how it fails.

It's tempting to think that the way to sort this out is to centralize it. But
in my experience, centralized document-management systems are _not_ that
intuitive, which drives people to secretly work around them. ("Why can't I
save my changed document on the shared drive? Oh, no, Joe checked it out and
then went on eight-week vacation! I'll just stash my edited version on my
local drive and distribute it via email." Or, "I created an alternate version
of the doc, but I don't dare upload it to the shared drive because I might
make another mistake and overwrite the official version. That always makes the
admin really mad. So here it is on this USB stick.")

I think the most confusing aspects of version control are the navigation of
history (just look at the wacky extreme that Apple' Time Machine designers
went to in order to make it very obvious that you're looking backwards in
history), and merging, particularly merge conflicts. But those aren't special
features of DVCS; they're tricky no matter which VCS you use.

