

Subversion’s Future? - davidw
http://blog.red-bean.com/sussman/?p=90

======
fendale
I have just got a rather large team ( > 100 people) using Subversion - from my
experience, I noticed two things.

Firstly, most developers I have encountered in big corporations (and India)
don't even give version control a thought - I thought it was programming 101,
but I was shocked about the resistance I got when trying to persuade the team
to use anything.

Second, the people I was trying to get to use version control could barely
grasp the basics - branching, merging, frequent checkin's, updating your
working copy - alien concepts - and that was using Subversion. I cannot even
imagine trying to convince them to use a distributed model!

So my point is - distributed version control is probably great (I have never
used it, but I have read a bit) for the clued in 20%, who work with others
from the 20%, but if your team involves people mostly in the 80% don't even
think about it - Subversion will have a market there for a long time to come
...

~~~
danohuiginn
_I cannot even imagine trying to convince them to use a distributed model!_

You're assuming distributed version control is harder to understand than
centralised version control. That certainly hasn't been my experience.

Using svn or cvs, I find myself rummaging round in the docs to do even quite
basic things ('recursively add everything in this directory', 'maintain a
personal branch of an open-source project, and keep it in sync with new
releases'). I've found bazaar and mercurial much more intuitive.

Maybe my experience is atypical. Maybe it's because of the particular
qualities of the programs I've used, rather than centralised vs. distributed.
But it's not obvious that distributed is harder.

~~~
fendale
You may well be correct - perhaps the distributed tools are easier - I need to
get one of them installed so I can play around with it to figure it out.

That said, if people don't get version control at all (yip, there are plenty
of them) then its probably going to be harder to convince them of the merits
of both version control and a distributed model at the same time.

I have certainly learned in the last few month that changing the direction of
a large team is no easy task, and convincing people to use any tool that is
even slightly off the beaten track is going to make that task even harder.

Its sad - I wish there were more curious, keen to learn people when I work!

~~~
mechanical_fish
The thing you're looking for is called "git-svn". It's built into git, and it
lets you use git with your office's svn repository.

You do have to accept some constraints in order to use it successfully --
basically, git-svn doesn't seem to understand merging back-and-forth between
different branches very well, so it encourages a much more linear, one-branch
workflow than git does -- but it is still a huge improvement over stock svn,
and it lets you inch your way into git, and gives you a platform from which
you can lure your fellow employees into git one at a time.

------
astine
He is correct, Subversion WILL linger on in the corporate world for a decade
at least. We're still using CVS where I work. We branch and merge every change
we make and management still considers SVN to be 'immature,' never mind Git.

Companies just can't let go of legacy systems. That's why we still have
companies running Cobol systems on OpenVMS. The term 'legacy' sometimes means
permanent.

~~~
umjames
You're right. We use CVS at work, but I'm the only one who uses it the way it
was meant to be used.

I've seen my co-workers, boss, and the consultants we've hired check in output
files as well as source files and make commits with no comments. Forget
branching, merging, and tagging. Unfortunately, in IT departments, you cannot
assume people know anything about source control, even in 2008.

All I can say is thank god I don't have to touch their CVS modules, and thank
god they don't touch mine!

------
neilc
I'm not sure how he can honestly call Subversion a "best of breed" centralized
VCS while it still doesn't support merge tracking in a stable release.

And is it just me, or are the use cases for SVN proposed in the developer's
mail he links to fairly limited? Making SVN "the best tool for organizations
whose users need to interact with repositories in complex ways" is fine and
useful, but they're essentially conceding that the DVCS approach is a better
fit for most open source projects.

<http://svn.haxx.se/dev/archive-2008-04/1020.shtml>

~~~
jrockway
DVCS is pretty much the best approach for anything. Centralized version
control systems might be OK, but SVN is not OK. The whole "everything is a
directory" model was a huge failure. Replacing CVS by eliminating the one
thing that it got right -- first class tags and branches... yeah, great idea,
guys.

Anyway, SVN's time has come and gone, and if I were the author I would
deprecate it and never look back. It was excellent while it lasted; it didn't
lose data, it was somewhat fast, and it got people into version control. But
now it's an ancient relic; its existence serves as a great example of how not
to implement a version control system.

Sorry if I sound harsh, but ... it's time to let go :)

~~~
davidw
I don't see why people get so excited about version control, myself. There are
so many other areas of tech where it's more productive to follow the latest &
greatest, or learn about new techniques. Sure, istributed is an improvement,
but for many people, even CVS would be "good enough".

BTW, you do sound a bit harsh, and I hope they continue to maintain SVN for
many years to come. It's sort of a thankless job compared to working on
something new and flashy, but I'm glad people put that kind of dedication into
their open source work, instead of just chasing after the latest fad.

~~~
jrockway
> I don't see why people get so excited about version control, myself.

Well, for most programmers it's one of their most frequently used
applications. Subversion is annoying because operations are really really
slow. "svn ci" takes forever as it slowly calculates changes, sends them to a
remote server, waits for svn to slowly update its database, and finally wait
to get a response back. I want to commit my changes, not take a 15 minute nap.
Git creates a few files, and it's done. Commits are instantaneous.

Subversion also has other annoyances. If you want to save your changes before
updating, that's too bad. "svn update" can destructively modify your working
copy (with no way to revert), and there's no way to commit when Subversion
decides that your working copy is out of date. You have to merge upstream
right then and there, so fuck you. This means that you have to make a copy of
your working copy with "cp" just so you don't lose data. Then you have to
manually merge. What!? This makes me pine for the days of "foo.c",
"foo.c.BAK", "foo.c.BAK.OLD", etc. ;)

Git handles this the right way. You can commit your changes whenever you want.
They're saved forever, and you can always get back to this state. If you feel
like pulling in upstream, you can. You then have the opportunity to merge, or
say "fuck the merge" and forget it. Git doesn't care when or if you merge
upstream into your working copy. You're never forced to do anything; you
decide how to work, the computer doesn't tell you what to do. (You can even do
it non-linearly; make a branch "foo", do the upstream merge in "master", pull
a few upstream changes from "master" into "foo", work on that for a while,
pull the rest of the changes in, and finally merge foo into master and send
master back to the server. Git handles all of this perfectly, so instead of
worrying about what the version control system wants to do, YOU get to decide
what to do.)

Finally, Subversion, despite its marketing hype, has no support for branching
and merging. Yeah, it has "cheap copies" that you can use diff3 against. What
a joke. (SVK is better.)

Anyway, please don't think I'm some rails weenie that just switched to Git
last week because some blog told me it's cool. I've been using it for over two
years, not because it's cool but because it instantly made programming more
enjoyable.

Like I said, I don't want to be too mean to Subversion, since that's never the
way to advocate something ... but switching from Subversion to Git feels like
ending an abusive relationship. You don't realize how bad it was until it's
over.

~~~
neilc
I think "svn ci" sometimes being a little slow is a total non-issue, at least
in my experience. Admittedly, the project I use SVN for is only ~750KLOC, but
I think that probably includes the vast majority of people using VCSs for
source code.

    
    
      Subversion, despite its marketing hype, has no support for branching and merging
    

That is overstating the case (SVN supports _branching_ just fine), but I think
that is SVN's only real problem is how terrible merging is (that and the whole
centralized model in general, but there are plenty of circumstances in which a
centralized VCS is perfectly acceptable). Hopefully merge tracking in 1.5 will
improve things.

~~~
jrockway
_I think "svn ci" sometimes being a little slow is a total non-issue, at least
in my experience._

Well, if you haven't used git, you don't know what you're missing. "svn ci"
seems fast. But try git and you will be amazed.

 _SVN supports branching just fine_

No, it supports cheap copies. It has no idea what a branch is. As far as svn
is concerned it's a directory. (You can even "svn copy" a single file. People
do this, and it makes the nightmare called merging even more of a nightmare.
Araaggghhh!)

------
jrockway
Reading the linked mailing list post, it seems that Subversion shouldn't even
self-host anymore. That is sad :)

------
axod
In other news, p2p killed off websites.

