I used SVN very early in my career. I think the only good thing I can say about it is that it's easier to learn. It's quite easy to teach a junior dev how to use SVN. Git takes much longer to master.
1. The trivial commit graph makes some concepts easier. You know from the commit number which is more recent. There are no complex merges.
2. The above makes for useful GUIs. There are no git GUIs that a user can not aim at their own foot, and needs the real client to clean up the mess.
3. The lack of complex operations makes access control easier. You still have to manage hooks, but it's easier or at least with less unintended consequences.
4. All clones are sparse. Together with a zero copy data storage makes for some cute concepts, such as branches and tags and directories actually being the same object. Sparse clones can be very useful.
5. The system tracks file system operations, such as moves and copies. It can actually be used for things, directly and without heuristics. (This is actually the one point where I can say I prefer the svn way. Git could have done something similar without breaking the conceptual model and it would have been useful.)
6. The metadata is, or at least used to be, more developed for non-unix file systems. I'm not sure if this is still the case.
7. Storing binary data is somewhat less bad. But still bad.
All that said, outside of specialized applications I'm not sure there's much reason to use svn for any new projects. And if you use it, keep in mind that git works perfectly well with svn archives. They just become a linear graph with funny commits and you can use that familiar git tools.
8. Naming of commands is sensible and inline with other similar tools.
9. No major issues with large files in your repo.
10. No flamewars break out online if you admit you don’t understand how part of the tool works.
The truth is that git is pretty abysmal overall. There are commercial offerings that easily surpass it, if you are willing to pay.
[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-...
[2] https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...
That's one thing I doubt Git will ever be able to do since it is a distributed model rather than server-based.
It's called Oxen and is initially targeted towards unstructured machine learning datasets, but could be good for this use case as well. Would love to get any feedback on it!
This is pretty much it, ease of use. No one really knows git (beyond 5 commands). Everyone knows how to google git commands or talks to the wizard in the company that can fix the mess someone created. While in theory git is more powerful, in the art of getting things done easily SVN wins, simple, stupid and it works.
For my case: one|two developers + hundreds of read-only observers + a number of patch senders it is a perfect tool that far.
TortoiseSVN (Windows) and analogous tools (MacOS and Linux) are really unbeatable.
I am also using Git time to time but that is really far usability wise.
Five commands: commit, update, revert, merge and switch combined with FS explorer visualization are perfectly enough. Rarely: shelve(create patch) and unshelve(apply patch).
That said, SVN works, and I do think the learning issue is the primary obstacle for us moving to Git.
It should be said we're a small team though, 10 devs. I can imagine Git looking a lot more attractive to a larger team.
I had to give several talks to existing and new employees about how Git works and how to use it. I was also that #1597 guy (https://xkcd.com/1597/). Back then most hires didn't work with Git before joining us, today of course it's different. Over time, all projects moved to Git as whenever someone was working on two projects, one Git and one SVN, they would ask "why is this still on SVN?" and soon it would be on Git.
Exactly!
Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but haven't seen that being used anywhere really.
Yeahhhh. Svn is centralized. You must be connected to the server to do any source control work. There is no local repository, there are no local commits. Every commit is global on the server. When you make a commit, it is pushed to the server and your coworkers can fetch it. You don't make commits locally and fiddle around and then push.
Also Svn doesn't have branches per se. You just use subdirectories. It does have facilities for merging directories and managing these "branches", but it feels real weird to be switching branches with 'cd'.
It's a very different world.
A quick read: https://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html
Also, this means that it's possible to do some horrifying things with branches and tags, like making a merge commit which is isolated to a single directory, or checking out a tag and making a commit to it.
Hopefully no one is actually depending on these workflows being possible, because they make project history extremely hard to follow.
That's not correct technically speaking. You can create repository on your machine - on local FS.
But of course it is more reliable to run it on server, even for yourself. If on Windows then VisualSVN is one click solution for those who just want to have that thing working.
SVN client supports equally well as "svn:" protocol as "file:". Server is not mandatory with SVN - you can work with repositories on your local HD or network share.
Your argument that this cant be done in svn because "there's a central repo" could have been translated in "git" as: "yeah you cant work on your machine without internet because you wont be able to push on github"
How are you merging without branches?
Git is mostly faster and more flexible than svn, and the merging works far better. Unless svn's merging has improved in the past decade or so, which is entirely possible.
When I switched to git from svn, the main differences were: merging was usable, making new branches and switching branches and such were _instant_ instead of many seconds, and I could work more flexibly (git doesn't require being connected to the server).
I certainly wouldn’t call SVN modern but it’s very well maintained and has never lost code on me. Many git-like features also exist now such as being able to stash some changes in order to pivot to something else for a bit. Except for the central server being a problem for some use-cases, SVN just works.
As I said, I haven't used SVN. It just seems like perforce and mercurial are basically "identical" for the ways I use them at least.
Much better working merges was reason many people moved to SVN but since then SVN just got better at it
When you've got a ton of projects and their associated deployment pipelines all using SVN, the cost of migrating is non-zero. Someday I'll probably start (slowly) migrating, but the benefits just aren't great enough to make it a priority.
E.g., people always like to point out that git is decentralised and svn is centralised. Bullshit. Centralisation and decentralisation are concepts, not absolute requirements. It's similar to the whole "you can't write object oriented code in c, you need c++" argument. Nope, you totally can. And also you can totally write completely non-object oriented c++. Case in point, most people who use git these days rely on a centralised use of git, namely through github. At my last job my use of svn was completely decentralised and worked like a charm.
I think the big thing for me is that, svn vs git shares a lot of similarities to the c vs c++ scenario: svn feels more low level, in that it is super flexible through its simplicity, but relies on good conventions as a result. git, on the other hand, tries to be opinionated about how things are to be done, and provides a specialised command for each task.
git feels very much like a "take-it-or-leave-it" solution to me. svn feels more like the early linux days: if you can afford to play around a bit to set up things just how you like them, then you can end up with a pretty sweet gig, that does exactly what you want it to.
Basically, the lead engineer that was in charge of the new project set up what he liked before the rest of the team was in place. So when I was hired on the team consisted of me, a senior engineer who hadn't used subversion in years, and a bunch of junior engineers who were completely unfamiliar with it. No amount of pleading would get him to migrate to git.
It was partially a control thing, I think. He liked having full control of the repo to himself. The system architecture was also... dated.
There is also this: https://github.com/msofficesvn/msofficesvn
1) adoption. You're early in the Adoption Curve and you're trying to grease the wheels to make it easier for people to come for you
2) modernization work. You're brought in to consult for a company because someone has declared moral bankruptcy and decided that neutral third parties are more likely to dig them out of the problem. So as a consultant you show up week one and you say, "Dear God, they're still using X?" about five times. So now you're proposing to do migrations that all of your peers finished up seven years ago.
We switched a year or so ago to use git sparse checkout that was released in 2.25.
<I am a git user, who prefers it to anything>