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

141–150 of 238 posts

Re: GitHub Sunsetting Subversion Support

#141

Post by oscillonoscope »

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.

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.

Re: GitHub Sunsetting Subversion Support

#142

Post by WorldMaker »

jeppester wrote: post #110
_da_ wrote: post #77

Earlier quoted context omitted.

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

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 don't know what your use case is, or why you don't have a local history anyway of the repo so that you need to spot-download sub-trees, but if this is a somewhat common workflow this seems to indicate you may possibly be looking for something like git-archive [1]. That's a tool included in the "corners" of the git "suite" to take a `treeish` and build a tar or zip directly from it (with no git metadata inside). You can use a commit or a tag name for a `treeish`, but if you wanted it to be a specific folder inside a commit you can pull the commit, examine the tree it points to until you find the tree ID inside that representing just the subfolder you are looking for. You can pass that tree ID to git-archive. (And other things that take a `treeish`.) It's not quite a "completely trivial oneliner" to write a script to do that, but it may not be that much more complicated of a script to write.

[1] https://git-scm.com/docs/git-archive

Re: GitHub Sunsetting Subversion Support

#143

Post by ynik »

avgcorrection wrote: post #105
gmueckl wrote: post #98

Earlier quoted context omitted.

Git doesn't have a good concept of a mainline branch when going back past a merge. It simply records more than one parent for that commit and not which branches they were on before they got merged. Mercurial does somewhat better in that department by storing the branch name in the commit, so you can pick the parent on the same branch reliably.

I don’t understand what you’re saying. If you have a main branch which is always merged into then `--first-parent` will only list merge commits and regular commits on that branch. I have never seen it fail on our main branch. In `git merge feature`, `feature` will become the second parent while the commit that you are on will become the first. The linear mainline history falls out of that.

It fails if someone merges main into their feature branch, and then performs a fast-forward merge of their feature branch to main. Now the two parents are in the opposite of the expected order, and --first-parent will follow along the feature branch. This can cause the new state of main to have a lower number of first-parent-commits than prior to the merge!

However, if you have infrastructure that prevents fast-forward merges to main (prevent developers from pushing directly to main, allow only PR merges and disable fast-forward merges for that), then the `--first-parent` approach can work.

Re: GitHub Sunsetting Subversion Support

#144

Post by Aachen »

snickerbockers wrote: post #130
IgorPartola wrote: post #65

Earlier quoted context omitted.

Instead add FTP version control support with the ability to create backup files.

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.

I didn't even use it all that often but, yes, I also feel like this was useful to have. Every now and again I come across an ftp site that I now have to copy into a dedicated program instead.

Re: GitHub Sunsetting Subversion Support

#146

Post by kejaed »

Shank wrote: post #13

This reminds me of when Slack shutdown its IRC bridge [0], and in a pretty negative way. I get that usage is down, but that tends to happen. Supporting niche users is how you win customer goodwill. The active users of SVN on GitHub clearly aren't going to switch to git, and I can respect the maintenance costs, but they're probably just going to switch to a different provider. For them, their workflow is now in-danger…

I relate here with Atlassian discontinuing their Jira Server product. I suppose they did the analysis and it wasn’t worth their dev time but there are some customers who CANT move to Jira Cloud for compliance reasons.

So now we are stuck. Stick with unsupported Jira Server, pay $40k/yr for Jira Data Center (!!) or switch with all the business costs associated with that.

Re: GitHub Sunsetting Subversion Support

#147

Post by avgcorrection »

ynik wrote: post #143
avgcorrection wrote: post #105

Earlier quoted context omitted.

I don’t understand what you’re saying. If you have a main branch which is always merged into then `--first-parent` will only list merge commits and regular commits on that branch. I have never seen it fail on our main branch. In `git merge feature`, `feature` will become the second parent while the commit that you are on will become the first. The linear mainline history falls out of that.

It fails if someone merges main into their feature branch, and then performs a fast-forward merge of their feature branch to main. Now the two parents are in the opposite of the expected order, and --first-parent will follow along the feature branch. This can cause the new state of main to have a lower number of first-parent-commits than prior to the merge! However, if you have infrastructure that prevents fast-forwa…

> However, if you have infrastructure that prevents fast-forward merges to main

I did say merge, did I not? Yes.

> > If you have a main branch which is always merged into then

If fast-forward is a “merge” too then fuck it, I can’t be bothered to use Git lingo since every idiotic little thing needs to be qualified (see also: Git tag, which is sometimes only an annotated tag but also sometimes also its cousin “lightweight tag”).

I guess I should have said “merge merge”. Huh.

Re: GitHub Sunsetting Subversion Support

#148

Post by maegul »

schacon wrote: post #12

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done. We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it…

I recall needing/wanting to clone only a specific folder from a repo and the best solution being to use SVN. I'm pretty sure I used that trick a few times and even shared it a couple of times. Don't know if it's possible with git now, but that was how I discovered this feature and it seemed eminently useful to me at the time!

Re: GitHub Sunsetting Subversion Support

#149

Post by Aachen »

c-smile wrote: post #94
coldpie wrote: post #69

Earlier quoted context omitted.

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

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

Re: GitHub Sunsetting Subversion Support

#150

Post by Aachen »

issafram wrote: post #113

This part made me laugh "Late in 2023, we’ll run a few hours-long and then day-long brownouts to help flush out any remaining use of the feature." I'd prefer just spam emails saying the system is shutting down

And after the email spam, it just shuts off? Wouldn't a temporary outage be a better way to attend those not reading the old email box used to sign up for Github that they need to upgrade their software?
Post reply on HN