5 ms·

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

by kypro 4y ago

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.

gowld 4y ago
"easier to use" a great reason to prefer it. I want to write software, not manage a source control system.
- c-smile 4y ago
  "I want to write software, not manage a source control system." Exactly!
gmueckl 4y ago
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.
jcadam 4y ago
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.
somerando7 4y ago
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.
- coldpie 4y ago
  > I haven't used svn 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 https://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html
  - duskwuff 4y ago
    > 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.
  - c-smile 4y ago
    > 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.
    - Aachen 4y ago
      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?
gus_massa 4y ago
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.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
histriosum 4y ago
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.
- sofixa 4y ago
  Git is much better at it nowadays thanks to Git LFS which just stores the blobs.
  - detaro 4y ago
    in exchange for yet another set of things to worry about to explain to/debug for non-technical users.
    - sofixa 4y ago
      I don't think the intended audience for Git LFS is non-technical users.
      - detaro 4y ago
        Then why do you mention it in response to someone describing their use of SVN because it's better for non-technical users?
- mananaysiempre 4y ago
  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). [1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ https://github.blog/2020-12-21-get-up-to-speed-with-partial-... [2] https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/ https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...
ProAm 4y ago
> 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.
- tcoff91 4y ago
  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.
  - OkayPhysicist 4y ago
    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.
satya71 4y ago
> 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. There is also this: https://github.com/msofficesvn/msofficesvn https://github.com/msofficesvn/msofficesvn
jaywalk 4y ago
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.
magicalhippo 4y ago
We use SVN still. I'd like to switch to Git soon, given tooling like CI/CD is better/more available with Git, but apart from that it works. 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.
- rsstack 4y ago
  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/ 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.
  - scarface74 4y ago
    I worked for General Electric back between 2012-2014. My department brought a trainer in who worked for GitHub for a two day class on git.
c-smile 4y ago
I am using it for Sciter development. 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).
juangacovas 4y ago
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.
jwcooper 4y 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.
mdaniel 4y ago
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 https://www.virtualbox.org/svn/vbox and /svn/kstuff-mirror and /svn/kbuild-mirror
xorcist 4y ago
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.
- thewebcount 4y ago
  I’ll add to that: 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.
hinkley 4y ago
Migrations exist for two reasons: 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.
oscillonoscope 4y ago
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.
P_I_Staker 4y ago
Less of a problem with LFS, but it's simple, functional, and you can store whatever large files without any worry. <I am a git user, who prefers it to anything>
tpoacher 4y ago
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.

by kypro 4y ago

gowld 4y ago

"easier to use" a great reason to prefer it. I want to write software, not manage a source control system.

c-smile 4y ago
"I want to write software, not manage a source control system." Exactly!

gmueckl 4y ago

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.

jcadam 4y ago

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.

somerando7 4y ago

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.

coldpie 4y ago
> I haven't used svn 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 https://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html
- duskwuff 4y ago
  > 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.
- c-smile 4y ago
  > 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.
  - Aachen 4y ago
    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?

gus_massa 4y ago

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.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

histriosum 4y ago

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.

sofixa 4y ago
Git is much better at it nowadays thanks to Git LFS which just stores the blobs.
- detaro 4y ago
  in exchange for yet another set of things to worry about to explain to/debug for non-technical users.
  - sofixa 4y ago
    I don't think the intended audience for Git LFS is non-technical users.
    - detaro 4y ago
      Then why do you mention it in response to someone describing their use of SVN because it's better for non-technical users?
mananaysiempre 4y ago
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). [1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ https://github.blog/2020-12-21-get-up-to-speed-with-partial-... [2] https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/ https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...

ProAm 4y ago

> 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.

tcoff91 4y ago
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.
- OkayPhysicist 4y ago
  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.

satya71 4y ago

> 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. There is also this: https://github.com/msofficesvn/msofficesvn https://github.com/msofficesvn/msofficesvn

jaywalk 4y ago

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.

magicalhippo 4y ago

We use SVN still. I'd like to switch to Git soon, given tooling like CI/CD is better/more available with Git, but apart from that it works. 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.

rsstack 4y ago
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/ 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.
- scarface74 4y ago
  I worked for General Electric back between 2012-2014. My department brought a trainer in who worked for GitHub for a two day class on git.

c-smile 4y ago

I am using it for Sciter development. 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).

juangacovas 4y ago

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.

jwcooper 4y 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.

mdaniel 4y ago

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 https://www.virtualbox.org/svn/vbox and /svn/kstuff-mirror and /svn/kbuild-mirror

xorcist 4y ago

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.

thewebcount 4y ago
I’ll add to that: 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.

hinkley 4y ago

Migrations exist for two reasons: 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.

oscillonoscope 4y ago

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.

P_I_Staker 4y ago

Less of a problem with LFS, but it's simple, functional, and you can store whatever large files without any worry. <I am a git user, who prefers it to anything>

tpoacher 4y ago

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.