[loewenskind]

>Just because there are better alternatives now for distributed version control, doesn't mean that the centralized approach has suddenly stopped working.

Except that a distributed RCS can do everything a centralized on can. The funny thing is, this is the last argument used by people religious about SVN but even this doesn't stand up. SVN isn't even particularly good at doing centralized revision control. Do you work somewhere that you'll have to be able to prove what was in a given release? SVN can't do that since you can rewrite history with no way of detecting the rewrite. If this is not acceptable you'll have to buy Fisheye.

SVN on it's own isn't useful for much of anything. It's only after applying several other commercial products that you finally get something only substandard.

[CrLf]

You forgot the piece that SVN integrates with IDEs. This is it, case closed.

Like I said, in most cases you are trying to convince developers that don't want to use any kind of version control. They want IDE integration, they won't use branches or any other features (some won't even know what the hell "branches" are), they will only use version control as a means to have a centralize repository for the code.

And they use Windows.

SVN solves the problem. It's either SVN or something worse (CVS and SourceSafe are still widely used).

Version control is a tool. You have a set of requirements and you choose the tool based on those requirements. There is no such thing as "obsolete".

[loewenskind]

>You forgot the piece that SVN integrates with IDEs. This is it, case closed.

IDE integration makes more sense with file focused systems like ClearCase. With "whole picture" focused systems like SVN, Git, etc., the value of IDE integration is less because you check in whole change sets at once. The only IDE I've ever seen that dealt with this reasonably well was Smalltalk.

>They want IDE integration, they won't use branches or any other features (some won't even know what the hell "branches" are), they will only use version control as a means to have a centralize repository for the code.

DVCS can do exactly this. Set up a hook so that e.g. Git pushes to a central repo on commit. You don't need to teach them about branches or any of that, just give them something simple.

By doing just this much you get automatic local "backups" of the repo and you get vastly better protection against corruption and tampering.

>And they use Windows.

No problem. Mercurial, for example, supports windows very well. Including a Tortoise interface that is (IMO) better than what SVN provides.

>SVN solves the problem. It's either SVN or something worse (CVS and SourceSafe are still widely used).

That may have been true 5 years ago but it just isn't today.

>Version control is a tool. You have a set of requirements and you choose the tool based on those requirements. There is no such thing as "obsolete".

This is a pretty ridiculous statement. Of course there is a such thing as "obsolete". When an alternative comes along that does everything its predecessor did, better and even with extra features on top of that then it has fully obsoleted said predecessor. This happens all the time in software. SVN fully obsoleted CVS. C fully obsoleted B. On and on.