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

161–170 of 238 posts

Re: GitHub Sunsetting Subversion Support

#161

Post by doublepg23 »

haileys wrote: post #151
snickerbockers wrote: post #130

Earlier quoted context omitted.

i'm still angry at mozilla and google for deprecating that, being able to set up a simple anonymous FTP server and send normies a link to it that they can open in their browsers was really convenient. Now if I want to use FTP i have to explain to them that they have to copy it into the windows file explorer or download filezilla.

Why not an HTTP server with a directory index? FTP is a pretty clunky protocol: it's round-trip heavy, not friendly to NAT on the client-side when you don't use PASV, not friendly to firewalls on the server-side when you do. I'm not sure what benefits there are to it these days.

Yeah a simple `python3 -m http.server` works pretty well.

Re: GitHub Sunsetting Subversion Support

#162

Post by sedatk »

thaeli wrote: post #21

The one thing I really miss about svn is the central,authoritative, auto-incrementing revision numbers. Git hashes are less friendly to use - in the svn days it was easy to tell at a glance if you had an earlier or later version. Yes, I know the many ways that git is better in practice, and would miss some of the workflows git's nature allows if they were gone. But we really did lose something too, especially when ru…

Mercurial supports those, but they're only guaranteed to be consistent per clone. So it mostly helps you when working locally. On the downside, inexperienced developers love to refer to commits by their sequential revision numbers, potentially causing confusion.

Re: GitHub Sunsetting Subversion Support

#163

Post by 1248 »

WorldMaker wrote: post #142
jeppester wrote: post #110

Earlier quoted context omitted.

With these features I can have a local clone with just a subfolder, and without downloading all the history. But it still comes with git - which I'll then have to remove for my use case. I really think that grabbing some files from a certain commit should be a completely trivial oneliner.

If you are already using GitHub you can write your own short scripts with GitHub's file raw URLs (which include a specific commit hash) and curl/httpie. Obviously, that's not easily portable to other hosts (though most of the big ones have similar URL patterns that you can discover), but depending on your use case may be a handy option. > But it still comes with git - which I'll then have to remove for my use case. I…

[dead]

Re: GitHub Sunsetting Subversion Support

#164

Post by justusthane »

admax88qqq wrote: post #92
scrollaway wrote: post #87

Earlier quoted context omitted.

You sound like the kind of person who thinks saying "it's just a prank bro" makes a variety of awful behaviour ok. AF is a day with a mix of corpos trying So Hard To Be Cool (remember this shit? https://www.theverge.com/2016/4/1/11344044/google-gmail-mic-... ) and plainer-than-usual disinformation campaigns. The only redeeming thing about that day is I get to have an excuse to not be reachable for a day and can be di…

Google used to have some great jokes though. TiSP was great. https://archive.google.com/tisp/index.html As with any prank or joke there is a skill and art to telling a good one. But I don't think we should let bad pranks outlaw humour in general.

That’s full of subtle gold:

> #6 Insert the TiSP installation CD and run the setup utility to install the Google Toolbar (required) and the rest of the TiSP software, which will automatically configure your computer's network settings.

As well as some less subtle jokes as well :)

Re: GitHub Sunsetting Subversion Support

#165

Post by tom_ »

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…

Perforce is still popular with games developers. It scales pretty well, even if you have tons of stuff in your depot, and since all the state is on the server the disk space cost locally is just the data. As you say, you can just put everything in there, and use it as your centralized file store for distribution of absolutely everything. Not unusual to have the CI system just commit the results back into Perforce, and that's how everybody gets updated builds or data.

History is per-file, so (in effect) you can treat any folder as a submodule, which simplifies having an enormous multi-project monorepo. This is something I've never done much with personally, but colleagues have had good results leveraging this to look after shared code that's used by multiple projects at different revisions.

The check in/check out model is also quite easy to reason about, and works well for the non-mergeable binary files that most games developers work with. (Programmers seem to kind of like it when they have some horrid complicated thing to get to grips with, that comes with a pile of new terminology and endless ways to cause yourself increasingly painful problems. Artists, designers and production staff... not so much.)

Main issues with Perforce:

- nobody seems to work on the product any more. If it's changed at all in the past 10 years, it's changed in some part that I, user of p4v (the GUI client) and p4 (the command line client) haven't found obvious

- the command line experience is pretty terrible, as it's inconsistent, and not very well documented, and the supposedly machine-readable output mode quite often just feeds you nothing more than an array of the same strings you'd see using the normal mode. But I can't deny that you can usually eventually get it to do what you want, provided you can assume the server charset

- the offline experience is rather poor! But this is increasingly less of a problem over time, and that process will continue

Somebody please figure out how to eat Perforce's lunch. We discuss this occasionally at work, but we're too busy working on actual projects...

Re: GitHub Sunsetting Subversion Support

#166

Post by c-smile »

Aachen wrote: post #149
c-smile wrote: post #94

Earlier quoted context omitted.

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

Re: GitHub Sunsetting Subversion Support

#167

Post by jacobr1 »

woodruffw wrote: post #67

Only partially related, but since they mention it at the bottom of the post: I really like GH's "brownout" approach to discontinuing services. They've done it a couple of times before (like this one[1]), and it's always struck me as a very sensible way to handle deprecations on such a massive service. [1]: https://github.blog/changelog/2021-08-10-brownout-notice-api...

We started using feature flags to disable, rather than enable capabilities. Turn them off and see if anyone notices. Ramp up the rate. If you identify some cohort that needs the feature, keep it on for them, but isolate them until you figure out a migration plan to close whatever gap you may have (or at least some way to massage unhappy customers if you aren't going to support some legacy thing).

Re: GitHub Sunsetting Subversion Support

#168

Post by jacobr1 »

thaeli wrote: post #21

The one thing I really miss about svn is the central,authoritative, auto-incrementing revision numbers. Git hashes are less friendly to use - in the svn days it was easy to tell at a glance if you had an earlier or later version. Yes, I know the many ways that git is better in practice, and would miss some of the workflows git's nature allows if they were gone. But we really did lose something too, especially when ru…

I've seen a number of places use the "Build Number" from their CI tool on the mainline branch to represent a similar notion. Presuming you've "centralized" things, this tends to work well.

Re: GitHub Sunsetting Subversion Support

#169

Post by spydum »

haileys wrote: post #151
snickerbockers wrote: post #130

Earlier quoted context omitted.

i'm still angry at mozilla and google for deprecating that, being able to set up a simple anonymous FTP server and send normies a link to it that they can open in their browsers was really convenient. Now if I want to use FTP i have to explain to them that they have to copy it into the windows file explorer or download filezilla.

Why not an HTTP server with a directory index? FTP is a pretty clunky protocol: it's round-trip heavy, not friendly to NAT on the client-side when you don't use PASV, not friendly to firewalls on the server-side when you do. I'm not sure what benefits there are to it these days.

Ftp is dead, just enterprise and mid level companies won't let go. It boggles the mind why it has persisted so long.

Re: GitHub Sunsetting Subversion Support

#170

Post by sicp-enjoyer »

thaeli wrote: post #21

The one thing I really miss about svn is the central,authoritative, auto-incrementing revision numbers. Git hashes are less friendly to use - in the svn days it was easy to tell at a glance if you had an earlier or later version. Yes, I know the many ways that git is better in practice, and would miss some of the workflows git's nature allows if they were gone. But we really did lose something too, especially when ru…

There is no immutable and consistent way to do this in a distributed system.
Post reply on HN