If it was two months ago, why did you start them out with obsolete technology? The only reason I can think of to have SVN today is legacy situations which you obviously weren't in.
SVN is far from obsolete. Just because there are better alternatives now for distributed version control, doesn't mean that the centralized approach has suddenly stopped working.
In most places centralized is the way to go. It may be unbelievable for the HN crowd, but most developers use only the bare minimum features of version control, and even then only after being forced to. In this scenario distributed version control causes more problems than it solves, not to mention the lack of integration with IDEs.
>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.
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".
>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.
Hey, at least they're using something. There's no need to waste time on a religious war within the church of version control, when there are non-believers who must be shown the light.
Bad attitude in my opinion. At some point they will have to do a costly and complicated migration to a modern system, and that could have been completely avoided by simply using a modern system to begin with.
>There's no need to waste time on a religious war within the church of version control, when there are non-believers who must be shown the light.
The only religious behavior I see here is claiming that a two systems are equivalent when they clearly are not.
>- windows support is still far from brilliant for git
It's not that bad, certainly not much worse than SVN itself on windows.
>- even a non-technical user can understand and use tortoisesvn in 2 hours
2 hours? A non-technical person can understand everything about e.g. Git that they're likely to need in less than that.
>- SVN revisions are really easy to understand
Not sure what you mean here. 1783. Is that somehow easier to understand than an equally meaningless hash key? At least in Git you could describe the version by the checkin text.
>but most of my non-technical clients are on svn
I think you're really doing them a disservice with this. As soon as they have any kind of accidental corruption I think you're going to be sorely missing Git's recovery capabilities and ability to mathmatically prove you're working with the version you think you're working with.
There may not be experienced developers who aren't using version control, but there are new developers all the time, especially on sexy platforms like Cocoa.
There was no version control available to me when I started programming BASIC on a BBC Model B in 1987. :) It's a bit of a different story in 2010. I would sincerely hope that anyone who aspires to be a professional developer would be aware that there is a thing called a version control system, and that using one is a Very Good Idea for all but the most trivial of programming tasks.
Many people who write code never aspired to be professional developers. Lots of people started by just trying pick up enough to quickly solve a small problem they where having while doing the thing they where actually interested in, then someone noticed that they knew how to program a bit, one thing leads to another and next thing they know they're spending most of their time programming.
Once you're used to something so fundamental, it's hard to imagine people won't use it as well :)