|
|
|
|
|
|
by mahyarm
4090 days ago
|
|
|
It's been 10 years since git has been released, and in my personal case when this happened, there wasn't any good reason other than 'it's what I know'. The company started with SVN when git had been around for a while. It's slowed down the company globally, prevents us from using various tools that don't have svn compatibility (like android's repo, gerrit or git's client side pre-commit hooks) and overall just been a relative pain the ass compared to git. The very small edge cases that svn might be better at now did not apply to us. Notice I didn't say perforce, or google's custom solution in my example. |
|
|
On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.
Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.
A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.
The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.
I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.