[HN Gopher] GitHub Sunsetting Subversion Support
___________________________________________________________________
GitHub Sunsetting Subversion Support
Author : mikece
Score : 163 points
Date : 2023-01-20 18:07 UTC (4 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| benatkin wrote:
| GitHub hasn't heard of Docker? It seems they could use it to run
| Subversion without any effect on their git hosting.
|
| Just kidding, but remember back in the DotCloud days when they
| pointed out you could run Perl? That was pretty cool.
| https://news.ycombinator.com/item?id=2518526
|
| > In 2010, when GitHub introduced Subversion support, the version
| control landscape was very different.
|
| That was waaaaay before Microsoft acquired it.
|
| > But hey, if the Subversion system just works and doesn't bother
| anyone, there's no reason to make any changes, right? The reality
| is that there's an ongoing maintenance cost to any software, and
| that goes extra for public-facing services on the internet. As
| the use of GitHub has evolved and the number of Subversion
| requests has declined dramatically, we plan to focus our efforts
| entirely on Git.
|
| Reminds me of how Microsoft dumped Atom (and then fauxpen-sourced
| VSCode before dumping the last remnants of Atom).
| czx4f4bd wrote:
| > Reminds me of how Microsoft dumped Atom (and then fauxpen-
| sourced VSCode before dumping the last remnants of Atom).
|
| I'm confused by this. Microsoft released the VS Code source in
| 2015, long before they acquired GitHub in 2018 and sunset Atom
| in 2022.
| benatkin wrote:
| They moved Atom into de-facto maintenance mode much earlier
| than that, when VSCode was much less fauxpen-source than it
| is now.
| czx4f4bd wrote:
| Just repeating "fauxpen source" doesn't mean anything to
| me. What actual change are you referring to?
| benatkin wrote:
| Big overview: https://ghuntley.com/fracture/
|
| A couple points in time:
|
| Pylance, installed by default, won't open source.
| Microsoft keeps calling VSCode open source.
| https://github.com/microsoft/pylance-release/issues/4
|
| Same for .NET https://twitter.com/migueldeicaza/status/15
| 37175065380495367
| IceWreck wrote:
| To add to the list, the c/c++ extensions, remote ssh,
| remote containers and intellicode are also closed source.
| carrja99 wrote:
| No!
| reindeerer wrote:
| github had subversion support ??? :)
| lopkeny12ko wrote:
| > But hey, if the Subversion system just works and doesn't bother
| anyone, there's no reason to make any changes, right? The reality
| is that there's an ongoing maintenance cost to any software, and
| that goes extra for public-facing services on the internet.
|
| This is a poor excuse. I understand that MSFT/Github feels
| compelled to provide a convincing reason to users, but this is
| not it. 99.9% of problems are caused by developers making changes
| or pushing new code. I've been writing software for close to two
| decades now--if you don't touch it, it's not going to break on
| its own.
| sastraxi wrote:
| The "ongoing maintenance cost of software" can also be the
| additional complexity in the mental model of developers that
| have to deal with nearby parts of the codebase. Even if no
| maintenance is needed for a specific feature, it doesn't always
| make sense to keep around.
|
| There's also knock-on effects, e.g. an offering like this could
| attract the type of user that would add a lot of additional
| support burden for the value that the company _and_ the user
| gets out of the feature.
| adamsb6 wrote:
| This reminds me of the time on Something Awful that radium banned
| the one user that was using WebTV.
|
| > About 91% of visitors are on Windows. Mac users make up 5% and
| Linux is 2%. The other 2% are permabanned IRC trolls browsing the
| forums with a text-based browser written in Ruby on OpenBSD. Oh
| yeah, we have one guy using WebTV but I banned him because WTF.
| mjhay wrote:
| Hadn't heard that one before. Radium's incompetence was really
| something.
| renewiltord wrote:
| I had no idea. This is fucking great. Hahaha. Best thing I've
| read all day.
| thaeli wrote:
| 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
| running git in "quasi-centralized" mode such as on GitHub.
| david_allison wrote:
| It can be done, but probably shouldn't:
| https://github.com/zegl/extremely-linear/commits/main
| rascul wrote:
| > With the shit ("short git") wrapper, you can use commands
| like shit show 14, and shit log 100..150
|
| I found this amusing.
| avgcorrection wrote:
| Maybe you can count the first parent commits on mainline, and
| then reverse that list.
| gmueckl wrote:
| 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.
| avgcorrection wrote:
| 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.
| scottlamb wrote:
| It's not as simple, but you might be able to get what you want
| with `git describe`. E.g., a working copy of mine now says
| `v0.7.5-43-g9060dbf`: 43 commits after tag `v0.7.5`, hash
| `9060dbf...`.
| woodruffw wrote:
| 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...
| travisjungroth wrote:
| Make sure to get the rate right. Like 1/1,000 or 1/100,000.
| Poetry did a brownout of its install script at 5% failure. With
| a matrix of builds user's CI had closer to a 100% chance of
| failing.
| js2 wrote:
| These are also known as scream tests. We use them internally at
| $dayjob as part of EOL'ing APIs. Are they not common?
| woodruffw wrote:
| I have no clue! I just appreciated them as a lowly user.
| thrownaway561 wrote:
| About time... I don't know a single person that still uses it. I
| can't tell you how many times I got burned doing merges in
| Subversion where the entire repo became corrupt. Git was a life
| saver when it came out and I switched immediately over to it.
| RcouF1uZ4gsC wrote:
| > I can't tell you how many times I got burned doing merges in
| Subversion where the entire repo became corrupt.
|
| Earlier in my career, in the first week at one company I ended
| up corrupting the Subversion repo. I was a nervous wreck. My
| boss reassured and told me about he had also corrupted a
| Subversion repo previously as he restored the repo from backup.
| david422 wrote:
| Uggh. If there's one thing I would want to be super stable it
| would be my version control!
| [deleted]
| kypro wrote:
| 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.
| xorcist wrote:
| 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.
| juangacovas wrote:
| 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.
| [deleted]
| gowld wrote:
| "easier to use" a great reason to prefer it. I want to write
| software, not manage a source control system.
| c-smile wrote:
| "I want to write software, not manage a source control
| system."
|
| Exactly!
| [deleted]
| hinkley wrote:
| 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.
| histriosum wrote:
| 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.
| mananaysiempre wrote:
| 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-...
|
| [2] https://github.blog/2020-01-17-bring-your-monorepo-down-
| to-s...
| dave78 wrote:
| 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.
| gschoeni wrote:
| 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!
|
| https://github.com/Oxen-AI/oxen-release
| sofixa wrote:
| Git is much better at it nowadays thanks to Git LFS which
| just stores the blobs.
| ProAm wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| jcadam wrote:
| 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 wrote:
| 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.
| kadoban wrote:
| > 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).
| arcticgeek wrote:
| 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.
| coldpie wrote:
| > 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
| duskwuff wrote:
| > 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 wrote:
| > 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.
| jaywalk wrote:
| 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.
| mdaniel wrote:
| 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
| jwcooper wrote:
| 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.
| magicalhippo wrote:
| 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 wrote:
| 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.
| c-smile wrote:
| 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).
| gus_massa wrote:
| 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.
| gmueckl wrote:
| 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.
| issafram wrote:
| 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
| voidfunc wrote:
| Didn't even know GitHub had svn support... it's been about a
| decade since I've even had to interact with a subversion repo
| professionally also.
| bradfitz wrote:
| They had Subversion support?
| CJefferson wrote:
| There is only one thing about subversion I miss when using git --
| the deletion of branches (which were, admittedly, just
| directories in a folder called branches) was version controlled,
| so you could recover deleted branches.
| nighthawk454 wrote:
| Just in case - you can in git as well. Branches are just
| pointers to a commit SHA, so can always create another pointer
| to the same commit and your branch is back.
|
| https://stackoverflow.com/questions/3640764/can-i-recover-a-...
| stouset wrote:
| I suspect GP knows this, but there's no way to go back and
| see what the branch ref was at a prior point in time. I
| believe they wish that refs themselves were versioned.
|
| And yes, I know they're kept in the reflog. But that is
| short-lived and (I believe) local rather than eternal and
| global like everything else in git.
| ecnahc515 wrote:
| The reflog does exist on the server too, but it's not
| really accessible without access to the git repo on the
| server, so not much use in eg, GitHub. That being said,
| GitHub also exposes some of these details, for example: in
| PRs when you force push on your branch.
|
| So in the general sense, there's no reason we can't have
| exactly what's being discussed, but it just doesn't exist
| yet.
| stouset wrote:
| > The reflog does exist on the server too, but it's not
| really accessible without access to the git repo on the
| server
|
| Though it only logs refs that the server itself has seen,
| which is more or less what I meant by "local". None of
| its state is shared during push/pull, it's computed
| entirely based upon what some individual client/server
| directly observes.
| CJefferson wrote:
| Yes, as you say, I'd have to write the commit names down,
| and eventually they would get garbage collected.
|
| You could tag, but then you are just polluting your tag
| namespace with old branches.
| kawsper wrote:
| I miss the name, SVN was pronounced Svend (SVeN) among my
| friends, which is a scandinavian male name.
|
| "Have you committed your changes to Svend yet?", "No, Svend is
| experiencing some downtime right now", that was some fun
| interactions that got us through computer science.
|
| Git is a fun name too, but it is not nearly as funny to me.
|
| TortoiseSVN was a great SVN client integrated into Windows File
| Explorer, and it looked great when you used the classic theme
| on Windows XP.
| Arnavion wrote:
| Conversely, the deletion of branches is version-controlled in
| git, because when someone force-pushes or deletes a branch on
| the remote it can still be restored from anyone's clone :)
|
| I've seen this happen a few times with a dev running `git push
| -f` with the intent to update their dev branch, except that it
| would force-push all branches in their clone that were
| associated with the remote, like master. It probably doesn't
| happen these days though, because the default was changed at
| some point to only push the current branch.
| rr808 wrote:
| How about Visual SourceSafe? I actually loved that for a small
| team.
| TimTheTinker wrote:
| Jeff Atwood had a lot of negative things to say about Visual
| SourceSafe back in 2006: https://blog.codinghorror.com/source-
| control-anything-but-so...
|
| There's some good links there that describe the trouble VSS
| caused.
| rr808 wrote:
| Lol the comments. I went through Perforce and ClearCase too.
| msoucy wrote:
| I try to forget ClearCase.
|
| It haunts my nightmares.
|
| When we were migrating to git, some of the more senior
| engineers came up with a workflow that was described as
| "the best implementation of ClearCase in git that I've ever
| seen". It was meant as a compliment.
| tialaramex wrote:
| Are you serious? I'm not even sure if Visual SourceSafe is
| better than "Once a week I copy all the files into a ZIP and
| date it" as a strategy for version management.
| msbarnett wrote:
| for one thing, zips are far less likely to destroy data than
| sourcesafe, which was famous for doing just that
| pianoben wrote:
| We used it at my first job, up until a disgruntled contractor
| locked every single file in our repo on the day he got fired.
| We couldn't do a damn thing for like a week, until we migrated
| to... TFS, sadly, but even _that_ was an improvement.
| ianmcgowan wrote:
| Worst. VCS. Ever! Can't believe anyone ever loved VSS - it was
| constantly corrupting the repository, people would lock
| programs and go on vacation, just a constant struggle.
|
| We switched to CVS and it was immediately better, followed by
| SVN a few years later. I still use git like a fancy subversion,
| just with multiple repositories :-)
| masklinn wrote:
| > I actually loved that for a small team.
|
| That's a joke right?
|
| VSS is by far the shittiest VCS I've had the displeasure to
| use, though I will confess I never had to suffer through RCS
| and CVS.
|
| It's certainly the only one which managed to destroy data.
| 'twas a good thing I'd already used other source control
| systems before VSS, because that experience would definitely
| have made me flee from source control systems for a while (much
| as Java did static type systems).
| arcticgeek wrote:
| We used to call it Visual Source Shredder because of how easy
| it was to corrupt the database.
| doublepg23 wrote:
| Not sure I'm familiar with any projects using Subversion. I think
| the most odd-ball version control I've seen in prod is SQLite
| using Fossil (which does seem to have benefits over git) and
| OpenBSD sticking with CVS.
| arp242 wrote:
| Apache httpd uses subversion.
|
| That's the only example of a well-known project I could find
| that's not directly related to subversion itself. I'm sure
| there are others, but all the other ones I could recall have
| since migrated (usually to git).
| netol wrote:
| Well, I think it is a bit related, being subversion an Apache
| project: https://subversion.apache.org/
| jldugger wrote:
| SVN is a relatively sane option, especially before git was
| published. But in 2023 its mostly been replaced.
| avereveard wrote:
| SVN had a great feature set, and a great way to handle
| merges, and sane defaults.
|
| too bad they hit some limits as repos become larger and
| larger, tried to implement a new storage engine, and
| basically they never managed to iron out all bugs out of it
| in time, while the older storage engine entered feature
| freeze and was basically abandoned.
|
| I've been checking them for years, and there were file
| corruption issue for so long, I lost interest in tracking the
| status anymore, as by that point I wrapped my head around the
| git model.
| msbarnett wrote:
| > SVN had a great feature set, and a great way to handle
| merges, and sane defaults.
|
| Are you kidding? Subversion had a _notoriously awful_ way
| of handling merges, which was a huge driver of people onto
| Git as soon as it appeared. You truly had to have been
| there to believe it, but in all but the simplest of merge
| scenarios, declaring branch bankruptcy and manually moving
| things back into the target branch by hand was your only
| real option. Early to mid 2000s, the most common team
| branching strategy I saw with subversion was "there's only
| one branch and everybody does all the development in it
| because god help you if you try to put it back together
| after branching for something".
|
| It wasn't until well after the momentum was clearly in
| Git's favour and a huge chunk of the user base was gone
| that Subversion finally fixed it to not be complete
| dogshit.
| masklinn wrote:
| > and a great way to handle merges
|
| Nope. That took a very long while to be added. When the
| current crop of DVCS started appearing, one of their
| significant draw was actually that by necessity merges
| worked well. At the time, SVN made it extremely easy to
| fork branches, and almost impossible to merge them.
|
| Per the official doc (https://svnbook.red-
| bean.com/en/1.7/svn.branchmerge.basicmer...) merge tracking
| was introduced in subversion 1.5, released in May 2008.
| That's 3 years after the initial release of Git, Mercurial,
| and Bazaar.
|
| Before then you had to keep note of what you'd merged by
| hand so you didn't double merge it, and that was distinctly
| not fun.
| TillE wrote:
| Subversion fixed all the truly horrific things about CVS,
| it's quite adequate for centralized source control.
| kevincox wrote:
| Reminds me of Linus Torvald's Google Tech Talk on Git.
| https://youtu.be/4XpnKHJAok8
|
| > I see Subversion as being the most pointless project ever
| started, because the slogan for Subversion for a while was
| "CVS done right" or something like that and if you start
| with that kind of slogan, there's nowhere you can go. There
| is no way to do CVS right.
| jldugger wrote:
| I mean, he was definitely selling a product there. SVN
| was pretty good, barring the merge logic being a PITA.
| arp242 wrote:
| "cvs add image.jpg" and then discovering you can't just do
| that 2 years later after a fresh checkout was fun.
| petepete wrote:
| I was about to respond with WebKit but it looks like they
| switched to git last July.
| jakub_g wrote:
| Subversion was the main thing in opensource space in before-git
| before-GitHub mid-2000, when projects were hosted on
| SourceForge. Old times!
| singularity2001 wrote:
| Is there an alternative way to download select folders without
| svn?
| _da_ wrote:
| > 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.
| jeppester wrote:
| 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.
| schacon wrote:
| 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 actually completely worked on every repository we had and we
| all thought it would be great. Until nobody believed us. Which in
| hindsight we should have seen coming, since that was the joke,
| but nobody actually tried it. Then people tried it and it worked
| and they thought it was a trick or something.
|
| It was really helpful for people migrating from legacy SVN based
| systems to us (CI and stuff) but I'm surprised to some degree
| that it's still running 13 years later when nobody is really
| facing that issue anymore. And I'm still undecided if the joke
| was worth the massive confusion it caused. But if I'm pressed, I
| would say that I would 100% release it on April Fool's Day again.
| filmgirlcw wrote:
| Thank you for building this. Best 13 year "joke" ever -- and I
| do think it also did some good.
| [deleted]
| vtbassmatt wrote:
| As the PM who ended up finally killing it, I (on behalf of the
| team) thank you for your "joke" that wasn't really a joke. It
| did help some customers who had legacy SVN workloads land on
| GitHub.
|
| I wanted to announce this on April Fool's Day, but just
| couldn't make the timing work.
| schacon wrote:
| I tip my hat to your team and I owe you all beers, my
| friends. You are doing the lord's work.
| klyrs wrote:
| > 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.
| adamdusty wrote:
| I disagree. It would probably prompt a few support calls
| and emails, but otherwise I think it would be great.
| IgorPartola wrote:
| Instead add FTP version control support with the ability to
| create backup files.
| colonelpopcorn wrote:
| source.php.old.ReallyOld.bak.thistimeitsold.old
| m4tthumphrey wrote:
| source.php_newnewnew
| rezonant wrote:
| I wonder how much PHP source code is publically reachable
| out on the Internet because people would do this without
| realizing that modphp wouldn't treat it like a PHP file
| anymore, so an HTTP request to it would cause it to dump
| the file's source code.
| IgorPartola wrote:
| Exactly. When it is a small change, just comment it out.
| But when it's a large change, create a
| .old.backup.2013-12-07.dontdelete.
| snickerbockers wrote:
| 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.
| eterm wrote:
| Thank you.
|
| A few different SVN -> Git migration tools failed to migrate a
| large legacy repo at a previous employer. I thought I was
| doomed to be stuck on subversion forever.
|
| It was GitHub's migration that finally worked and got us
| migrated across.
|
| Funny we were only svn because I had previously been part of an
| effort to migrate them _to_ svn when I 'd joined a few years
| prior because before that they were using an old TFS system
| where developers would block each other by checking out files
| which would lock them for the whole repo.
|
| I knew that switching immediately to git would have been too
| much of a culture shock so I got them over to a CVS where
| people could at least work independently first. ( I also have a
| soft spot for svn anyway, I think for many small teams it works
| just as well as git with fewer opportunities to shoot oneself
| in the foot. )
| vtbassmatt wrote:
| FWIW we aren't planning to turn off Subversion import [1].
| Only the two-way bridge where you could keep using `svn`
| against the Git repo.
|
| [1] https://docs.github.com/en/get-started/importing-your-
| projec...
| pan69 wrote:
| If my memory is correct, the content on svnhub.com used to look
| different back then, was it related to the April Fool's Day
| joke?
|
| https://svnhub.com/
| vtbassmatt wrote:
| As part of the deprecation plans, I updated the look of that
| site to match modern GitHub branding a little better.
| COMMENT___ wrote:
| > I'm surprised to some degree that it's still running 13 years
| later when nobody is really facing that issue anymore.
|
| It's still running because Subversion has better CLI.
|
| PS The joke is not that funny when it lasts for 13 years. Ha-
| ha, how funny (not).
| flandish wrote:
| Y'all should sunset it on April 1st.
| joewadcan wrote:
| This was such a help when selling to Enterprises!
| butterandguns wrote:
| Where did the name slumlord come from?
| _a_a_a_ wrote:
| And I just want you to know that I know of SVN's shortcomings
| but I do like it's comprehensibility very much, and though I
| use git it has caused me a lot of unnecessary pain. FYI.
| ceejayoz wrote:
| > Until nobody believed us.
|
| I remember having this problem with Gmail's "1GB for everyone!"
| April 1 announcement.
| scrollaway wrote:
| I think April 1st should definitely be "Crazy-but-real
| announcement day". It'll take some attention off the
| unfunnier-every-year "jokes" which have turned a pleasant and
| fun yearly occasion into the internet being unusable for ~36
| hours.
| RockRobotRock wrote:
| You mean the internet being actually lighthearted and fun
| (like it used to be) for 36 hours?
| scrollaway wrote:
| 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
| disconnected for a while. Hopefully my loved ones don't
| end up in the hospital on bad timing.
| admax88qqq wrote:
| 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.
| krisoft wrote:
| BBC usually does a "stories which sound like april 1st
| jokes, but are actually true" compilation on that day. I
| always found it funnier than the real april 1st jokes. Also
| it kinda shows of their fact checking and news gathering
| muscles, that they are able to pull the crazy-but-true out
| of the sea of general crazyness.
| birdyrooster wrote:
| > when nobody is really facing that issue anymore
|
| heh heh heh, yeah nobody
| neallindsay wrote:
| 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 hosting the Linux kernel.
| And forget even about its distributed nature; Git was already
| better at the centralized model than "centralized-only" version
| control systems ever were.
|
| When Subversion came out I was overjoyed; finally someone had
| fixed most of the broken things about CVS. I jumped on it with
| gusto. But when Git came out it was so much better than SVN that
| I was blown away. And it wasn't long before there were great
| tools to translate between SVN and Git. By the time Github
| released its SVN bridge feature I think the place I was working
| at had already used those freely-available tools to move our old
| SVN repos to Git with full history. It was so easy to do! The
| only hard part was organizing all the developers to stop using
| the SVN server and switch to pushing to the Git server at the
| same time.
|
| Sometimes a new technology comes out and it's immediately obvious
| that it's the future. The ones that come to mind for me are Git,
| the iPhone, and node.js.
| yoden wrote:
| > I think it was actually extremely clear that Git would win.
| It had a guaranteed audience by virtue of hosting the Linux
| kernel. And forget even about its distributed nature; Git was
| already better at the centralized model than "centralized-only"
| version control systems ever were.
|
| I think you're forgetting about Mercurial, which was also
| created by a Linux kernel developer around the same time. It
| brought all the same benefits of git, but had a simpler command
| line API and better cross platform support. Mercurial saw wide
| use, especially in large corporations like Facebook.
|
| Indeed, a lot of people will say that it was the success of
| github itself that pushed git over the top. In a world where
| bitbucket won instead of github, we could all be using
| mercurial.
|
| Although I've never used it, I'm not sure how much of an
| improvement either of these was over BitKeeper. The primary
| impetus to create git and mercurial was licensing changes in
| BitKeeper, not technical deficiencies.
| neallindsay wrote:
| Maybe I'm the weird one, but Mercurial never made sense to
| me. I thought that Git's model made perfect sense.
|
| I never tried BitKeeper, so I can't speak to that. But being
| proprietary seemed to doom it.
| no_wizard wrote:
| 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 see part of the
| code. It was really good for monorepos.
|
| It has its quirks, and when I used it, could be a bit slower on
| the execution side, but generally thought it was really nice.
|
| I also maintain that Mercurial & Fossil are superior to git,
| but git won the marketshare so its kinda moot now.
| Shank wrote:
| 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 and they have to solve
| that problem in-addition to whatever they're working on. I always
| thought it was a lovely little feature GitHub supported, and I'm
| sad to see it go for this reason.
|
| [0]: https://it.slashdot.org/story/18/03/08/2049255/slack-is-
| shut...
| arp242 wrote:
| There's some differences as well: GitHub gives a year lead-
| time, Slack gave two months. IRC and XMPP are a fundamentally
| different workflows from that horrible web UI, subversion (for
| basic commands) is not all that different than git (alias
| svn=git can _almost_ work).
___________________________________________________________________
(page generated 2023-01-20 23:00 UTC)