Feature Handle github's removal of SVN gracefully

I

Irrat

Member
github.blog

Sunsetting Subversion support

On January 8, 2024, GitHub will remove support for Subversion.
github.blog github.blog
github.blog

Subversion brownouts · GitHub Changelog

Subversion brownouts
github.blog github.blog

For those of you that are unaware, SVN support in github will be removed on the 8th of Jan.
This was discussed before here: https://kolmafia.us/threads/implement-warnings-when-using-svn-with-github-projects.28617/ https://kolmafia.us/threads/update-...o-use-git-install-revisit-some-scripts.28672/
But this post isn't so much about that.

Instead, I'm thinking the following probably needs to be done.

1. We automatically skip over github when using svn update, and display a red warning instead
2. New installs could redirect to git instead, even if specifically using github

We shouldn't automatically reinstall git with an existing svn project via deleting and installing. The obvious reason being that scripts may lose custom changes.
But we could also possibly do something where a new command is added, "migratesvn". (If not done already), that could automatically reinstall those projects. But only if they are unmodified.

If my script installs a file, then the command could check if the remote file on github matches the file in our repo, and if the file in our repo matches the actual file in scripts. If any of that does not match, then we display a warning "Custom modified content" or something and move on. If someone touched their local script, then we'll note it but let the user resolve it.

That's just an idea though.
Short term, we need to inform the user about SVN, and skip over SVN github projects.
 
The existing KoLmafia behavior seemed acceptable to me when there was the temporary outage as a test in December. Previous discussions suggested that the fix needed to come from a script owner or someone who was willing to take over hosting of an abandoned script.

If a script hosted on GitHub and accessed by SVN is not being maintained or updated then there is no problem until an author with access to the GitHub repo decides to maintain it.

It could be argued that neither users nor script writers should be able to specify the protocol used to access the repository, only the repository location. Mafia should identify name conflicts where a script installed via one protocol will conflict with a script of the same name previously installed by another but the fix should be user initiated and not automated. This was once difficult because the check needs to be on the installed path name and not just the name of the script but I think the code that is already in place does that, at least within protocols.

I'm not sure I agree that there is a problem that needs to be fixed in KoLmafia but I am willing to "review" a design and then approve code that implements the design. Maybe you start by paraphrasing your first post as a list of steps/things that will be implemented?
 
Yeah, I have to admit I probably jumped the gun a bit here. I think I've also missed a discussion about this too.

That said, it'd probably be best to bank this until github actually sunsets SVN and the overall state of how things are affected is clear instead of my assuming.
 
I have not had time to find and confirm but I have a vague recollection that there are a couple of KoLmafia commands that will identify git and svn issues. I am thinking they are options to test or debug at the cli but I just have not had the time to find them. If I am right then there may already be a partial solution.
 
My plan is to just let things fail, and hope that Ezandora fixes her scripts while they're broken (and any other scripts that may be affected: I think it was just Ezandora's).

It might be worth adding something to the CLI after it's possible to fix all the scripts, but there are some scripts you can't fix at the moment.
 
checksvngit is the CLI command I was trying to remember.

It reports local files that appear to be in a GitHub repository but updated via SVN.

Mine are:
Local installation of Ezandora-FantasyRealm-branches-Release uses SVN to update from GitHub.
Local installation of Ezandora-Gain-branches-Release uses SVN to update from GitHub.
Local installation of Ezandora-PirateRealm-trunk-Release uses SVN to update from GitHub.
Local installation of Ezandora-Voting-Booth-trunk-Release uses SVN to update from GitHub.

checkrepo is also of interest since it looks for possible duplicates across SVN and GIT.

I wrote these in 2022 which is why my memory is flakey. Reconstructing my thinking I expected a user to run checkrepo to see whether there were any scripts that were possibly being installed from two different repositories. If there were duplicates then it was a manual process to figure out which repository was correct, delete the other one and then identify any scripts that might be reinstalled because they were dependencies using the "wrong" protocol or repository.

Anything identified by checksvngit should trigger one of several responses including uninstall from SVN and installing from GitHub with git or waiting for someone else to do something so that KoLmafia will find and install "properly" and then making sure there aren't any duplicates, i.e. run and resolve checkrepo.

I'm thinking we don't need any more code to deal with the sunset of GitHib via SVN. We might consider documenting these commands in some kind of user friendly manner but the folks who can't figure it our will probably ask anyway.

If someone wants to automate the process make sure there is a test that handles the case where the new maintainer of the script decides to host it on SourceForge and use SVN ;-)
 
Ezandora has now fixed her scripts, but they've changed to be installed from the default branch instead of Release.

I think our scripts json wants updating, and also all scripts which use one of Ezandora's scripts as dependencies should update to the new world.
 
You must log in or register to reply here.
Back
Top