Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

Post reply on HN
Print view View original

231–238 of 238 posts

Re: GitHub Sunsetting Subversion Support

#231

Post by rhaway84773 »

adamdusty wrote: post #85
klyrs wrote: post #24

Earlier quoted context omitted.

> I wanted to announce this on April Fool's Day, but just couldn't make the timing work. Thank you for not doing that. Releasing a wacky feature on April 1 is funny. Discontinuing a service that people might rely on is distinctly un-funny.

I disagree. It would probably prompt a few support calls and emails, but otherwise I think it would be great.

“A few support calls” = At least a few companies who have unnecessarily faced major enough issues that they worked through internal investigations of many different pieces in the stack and then eventually decided to reach out to external support for GitHub, potentially having reached out to other vendors’s support because some PM thought it would be “funny”.

I don’t actually think it would cause any problems personally, but I’m astonished at the flip dismissal of a “few support calls”.

Re: GitHub Sunsetting Subversion Support

#232

Post by thayne »

vmiklos wrote: post #212
thayne wrote: post #190

Earlier quoted context omitted.

A sparse checkout isn't quite the same thing. It still has to clone the whole repository, it just only puts part of it in the working tree. With svn, you don't have to pull down anything for other directories. More recently, you can combine a sparse checkout with partial clone to get more similar functionality, but it isn't exactly simple.

FWIW, it's called a shallow clone: https://git-scm.com/docs/shallow

That is yet a different concept, where it doesn't include the full history, but without a partial clone it still pulls the entire tree for the head commit.

Re: GitHub Sunsetting Subversion Support

#233

Post by P_I_Staker »

no_wizard wrote: post #119
neallindsay wrote: post #108

I remember when they added Subversion support; I thought it was hilarious. And it worked! This quote from the linked blog post made me raise my eyebrows though: > In 2010…it was not yet clear that distributed version control would eventually take over, and even less clear that Git would be the dominant system. I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hostin…

Just because I don't get to talk about this much, as far as centralized version control goes, I liked Perforce when I used it. It could store everything: assets, builds, source code all in one, and you could do fine grain checkouts (I think git structures this as shallow clones but they're hard to get right). It also let you put permissions on the repository itself, so if you didn't have the correct ACLs you couldn't…

Mecurial isn't superior to git, it's simpler. The stuff that people tend to "criticize" git for is useful complexity. Although, I suppose most of these features are available via extension now?

Re: GitHub Sunsetting Subversion Support

#234

Post by P_I_Staker »

kypro wrote: post #25

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.

Less of a problem with LFS, but it's simple, functional, and you can store whatever large files without any worry.

Re: GitHub Sunsetting Subversion Support

#235

Post by P_I_Staker »

dave78 wrote: post #95
histriosum wrote: post #55

Earlier quoted context omitted.

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…

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

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

Re: GitHub Sunsetting Subversion Support

#236

Post by P_I_Staker »

johnwalkr wrote: post #156
dave78 wrote: post #95

Earlier quoted context omitted.

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

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.

If you're using lfs for cad, it has file locking

Re: GitHub Sunsetting Subversion Support

#237

Post by tpoacher »

kypro wrote: post #25

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

Re: GitHub Sunsetting Subversion Support

#238

Post by tpoacher »

coldpie wrote: post #226
c-smile wrote: post #166

Earlier quoted context omitted.

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"

Post reply on HN