Is SVN still acceptable and how much worse is it compared to git? I was just transferred to a team which still uses it and I am debating whether I should just comply and learn it or to push for git.

SVN fails if you have thousands of devs world-wide on the same project. Since SVN has a central server, that approach just doesn't scale, and that's why the Linux kernel project needs distributed version control.

Otherwise, for smallish teams in the same office, SVN is fine and really nice with Tortoise-SVN.

Not acceptable these days IMHO. Git can do everything that SVN can do and more, and it's a very standard tool. If you don't understand how to use it, it's time to skill up.

Even if you're just using SVN centrally, it restricts everyone else's local working (can't create your own local branches, can't rewrite your own local history, etc.) - as well as creating a messier changelog centrally (no rebase, no squash and merge) and makes diffs harder to read (no rename support, directories aren't first class objs.)

It was fine in the day, but now it really is hopelessly outdated, and I can't see any sensible argument to use it on a new project.

Whether you should argue against its use in an established project is another matter entirely however.

@halfflat Needing to understand the implementation in order to use a program is a tell-tale sign of rotten software architecture with the implementation leaking through bad abstractions.

@halfflat There is a reason why so many open source authors host their projects at a closed source company on its proprietary servers, with the irony of using a DVCS for that as added bonus.

The success of Github is rooted in the technical capabilities of Git, but also in its insane UI because what Github mainly offers is a convenient way to bypass the UI.

Fwiw, I actually prefer mercurial all things being equal. Easier to use, commands make more sense, harder for newbies to shoot themselves in the foot.

Fact is though mercurial lost the VCS war, and git won - and there's not scope in industry for forcing someone to use your preference just because you prefer it over the standard.

Definitely force-push GIT on them!
Merging was hell in SVN - show them how simple it is in GIT (but configure meld as mergetool first) and they will happily git gud with GIT.

@Oktokolo Meld sucks - isn't there something on a par with Winmerge under Linux?

@Fast-Nop @halfflat
What do you mean when you say git UI? The command line interface?
If yes, then you give it too much relevance. There are many devs who use git exclusively with a GUI client like SourceTree and never use the command line.
This can not explain all of the difficulties of git.

@Lensflare Yeah the CLI is a completely insane and misdesigned potpourri with no sense of command consistency. The issue with a GUI shows when things fuck up.

Or just don't fix it, back up your work, nuke the local copy, check out again, overwrite with the changes from your backup (hopefully using a merge tool and not file copy). The xkcd method.

SVN has a habit of corrupting its database under hard-to-understand circumstances, and then you're completely screwed.

If you're gonna go with a centralized system, might as well jump in both feet first and go for Perforce.

@Fast-Nop
I don't know WinMerge.
What features do you miss?

@Oktokolo Speed. Just try to diff two text files of 10MB each, and it's ridiculous how Meld is choking. I'm not sure whether this is because it's in Python, or whether there are also bad algorithms involved.

@Fast-Nop
I never merged 10MiB files as code files are split way before they get that huge.
And i wouldn't expect meld to have any optimizations targeting SQL dump diffing or merging either.

But one order of magnitude probably gets added by Python itself. Using a Python compiler could reduce that factor...

@Oktokolo It's not just for code. Last year, I noticed that GCC embedded running on Windows generated a slightly different firmware than the same GCC version under Linux.

To find out what the difference was, I generated the annotated assembly listing (intermixed with C source code) as output and tried to compare them. Meld didn't take that too well while Winmerge didn't have any problems.

@Fast-Nop
That definitely boils down to: The makers of meld likely never needed to compare annotated single-file firmware assembly listings.
They probably never thought about similar use cases and would surely be pretty happy about pull requests improving the performance while not reducing the feature set.
Maybe, you could also trigger optimizations by filing a feature request.

But you could also just use WinMerge with Wine. It will probably work almost as fast as when run native. The startup time of Wine should be neglible when comparing huge files.