I'd love to hear from someone who's still using SVN professionally and can explain why they prefers it to Git.
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.
I don't "prefer" svn (or anything else), but if you are interested in what svn does differently than git, which can suit some use cases better, here are some suggestions:
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.
SVN is still simply unsurpassed by any other open source version control I know when it comes to the handling of large files and fine grained access control.
The truth is that git is pretty abysmal overall. There are commercial offerings that easily surpass it, if you are willing to pay.
I use Subversion at my gig in several places. I don't use it to manage source code revision control, but I have several processes that require business users to manage binary files (such as audio files) in order for them to be automatically deployed to production. Git or Mercurial are pretty awful at this kind of role. Subversion let's me check out at a subfolder level of a repository, and not pay the cost of having the full revision history contents sitting in my clone.
Core Git is not the greatest at large binaries, so for that you indeed probably want an addon like git-annex or Git LFS or an alternative such as dvc, but in recent versions it absolutely can[1] only give you only part of the history or part of the objects: the former is known as “shallow clones”, the latter as “partial clones” (there are also “sparse checkouts”[2], but those only concern the working tree IIUC).
Similarly, we used to use SVN for a mechanical engineering team doing CAD models. SVN supported a reserved checkout mode (I guess SVN calls it "locking") which meant only 1 person could check out a file at a time. Perfect for non-mergeable binary files, and with TortoiseSVN it was easy for non-SW engineers to use.
That's one thing I doubt Git will ever be able to do since it is a distributed model rather than server-based.
File locking exists for LFS, which you could argue is the main place you'd need it... if you want to "lock down" other files, there's ways to handle that in the process, eg. pull requests
It does? That’s a requirement for version control for cad I think (just wrote a huge comment yesterday in here about it). I might actually try to use svn in 2023.
Been working on a version control system to solve this large binary file problem as well.
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!
> It's quite easy to teach a junior dev how to use SVN. Git takes much longer to master.
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.
I remember having all kinds of strange issues with subversion that were hard to resolve as a novice, not being able to commit for cryptic reasons, etc... Perforce is the only tool I've used that was actually pretty simple, and even then I'd say that dealing with merging streams was not nearly as easy as merging git branches.
Heh, funny story about Perforce. I bumped into one of their founders at a camp I go to, real down to earth dude. We had struck up a conversation over a few drinks, and the conversation drifted over to what we did. He asked "You know version control software?", and I replied "Like Git?" and he just responded with an exasperated sigh.
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).
As others have commented, my team at work use SVN because it's what somebody is confident to manage with svn+ssh protocol and want to keep it internal. Some projects use a "release" branch to which we merge when deploy is sensible, most projects haven't this branch and is just "trunk"/master. No more is needed. SVN works.
Almost a decade ago, I was part of a 10 person team (that was growing) and while there was consensus around transition to Git, it kept getting pushed back. I eventually forced the issue by changing the deployment job in Jenkins for one of the main projects to deploy from Git instead of SVN.
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.
What's better about git? I haven't used svn, but have used perforce/mercurial professionally/git professionally, and use git personally, but I find all of them to provide the same "feature set" when doing basic development: have your own branch, and merge it in to the main branch when done/reviewed.
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'.
> You must be connected to the server to do any source control work. There is no local repository...
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.
Am I understanding you correctly if I compare it to making the argument that, technically, you could run any Internet website from your laptop and network connectivity isn't actually required for using the web?
I am referring exactly to "must be connected to the server to do any source control work. There is no local repository..." which is plainly wrong by any means.
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.
"Server" was perhaps the wrong word. "Central repo", if you like, regardless of connection method. What I meant is that "svn checkout" does not make a new repository, as "clone" does in decentralized source control systems. You must interact with the central repository (wherever it is stored, locally or over the network) to do version control work.
I have used svn in a decentralised manner, pretty much as the person above me describes, for years. It's super simple to do. You create a local repo, populate it from "origin", and when you want to commit your local changes, you make a "foreign merge" request from "origin".
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"
> 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'.
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.
> I've heard that git branching is better(?), but haven't seen that being used anywhere really.
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).
Yes, that’s actually the thing about branching in SVN. Everyone remembers how awful it was 10+ years ago under SVN 1.4 and earlier but has improved immensely since then. Combined with modern client tooling, i.e. TortoiseSVN, problems with merging are almost non-existent for a long time.
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.
> 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.
Much better working merges was reason many people moved to SVN but since then SVN just got better at it
I still use SVN professionally, but new projects use git.
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.
My workplace still uses SVN. Easy to colocate code & hardware/mechanical files. For the kind of work I do, the advanced features in Git wouldn't really provide any benefit but changing would be a pain.
I used svn in my previous job, not out of preference, but because that's what the boss preferred. But, I have to say, as a user (who doesnt care about the under-the-hood-efficiency arguments) I don't get what the fuss is about.
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.
One of my friends is using it at work. They have been using SVN since a long time. They have been planning to migrate to Git for a few years. The problem is that customers pay for features, not for the version control you are using. SVN still works, and the inertia is not zero.
Not using it now, but the last project I was on that did was at a defense contractor about 5 years ago.
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.
> Why do people still use Subversion on GitHub, anyhow? Besides simple inertia, there were workflows which Git didn’t support until recently. The main thing we heard when speaking with customers and communities was checking out a subset of the repository–a single directory, or only the latest commit. I have good news: with sparse checkout, sparse index, and partial clone, Git can now do a pretty decent job at these workflows.
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 used SVN in an application to grab a single folder and its contents from a repo on GitHub. It was the quickest and easiest approach at the time (that I knew of) and worked well.
We switched a year or so ago to use git sparse checkout that was released in 2.25.
While I'm deeply thankful that I don't have to use it, the most famous one I know if is Oracle's VirtualBox: https://www.virtualbox.org/svn/vbox and /svn/kstuff-mirror and /svn/kbuild-mirror
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.