I have the same problem, but in Ubuntu 18.04 Bionic the repository exists. Did they forget to add the plugin to the repository?
I was able to install it by getting the .deb file contained in my old server with Ubuntu 18.04 from the apt cache located in the following path: /var/cache/apt/archives/ the file: webmin-virtualmin-svn_5.1_all.deb
I manually copied this file to my new server with Ubuntu 24.04 and installed it using the command dpkg -i webmin-virtualmin-svn_5.1_all.deb
“They” (me, I maintain the repositories) didn’t forget. The module is mostly deprecated. There just isn’t any reason to use Subversion in a world with git. We’ll fix obvious bugs, when reported, but we’re not doing anything new with it, and not recommending Subversion for anything.
What’s the motivation for using Subversion in 2024?
Thank you for the quick response and clarification. I apologize for using the term “They”, it must have been a translation issue since I am not fluent in English. The reason I am still using it is that my server has been a legacy systems server since 2016 and Ubuntu 14.04 or 16.04, at that time GIT did not have free private repositories and we had to use other alternatives such as BitBucket or others. Currently my server is with Ubuntu 18.04 which lost support for updates in March 2023. The work now is to reinstall a server from scratch with Ubuntu 24.04 and perform the backup through virtualmin of the server that is with Ubuntu 18.04 and restore on the server with Ubuntu 24.04. When trying to do so I got errors because this server contained subversion repositories and the webmin-virtualmin-svn plugin was not installed, when trying to install I did not find the package as mentioned in the documentation. These repositories need to be maintained so that there is enough time to migrate them to GIT. I suggest updating the documentation available at: Subversion and Virtualmin | Virtualmin reinforcing the deprecation of subversion, explaining that the plugin repository is no longer available, and recommending that people migrate to git, which makes perfect sense.
Git is not github. And, Virtualmin’s git module does not interact with github in any way.
And, yeah, I need to do something about the old website. Literally everything on archive.virtualmin.com is deprecated. I thought all the docs had a note to that effect, but something seems to have broken with that header in the intervening years. Probably should just take it down, but I’d want to redirect to the right docs on the new (now several years old) website.
Now I understand how it works, I really lost a lot during this time using subversion. But anyway I’m going to finish migrating the server in its current state, and then get rid of subversion once and for all by migrating the repositories to GIT using virtualmin git repositories plugin.
FWIW, our git support is also kinda suboptimal. It thinks about the problem like it thinks about the problem of Subversion, which was never a useful way to think about git. Git is a whole other way of solving the problem, and there is no “server” in a git deployment. Every copy is complete. There is no server, there is no client. You can push or pull in either direction, it’s just a matter of how you’re talking to the other end (ssh preferably).
My use of versioning is basic, that’s why I like subversion, I believe that this git solution will serve my demand by taking advantage of my own server and the resources of virtualmin. Currently I think it’s overkill to access github.com and create my repositories there as private, I won’t deny it, I have some, but I much prefer all of them on my server within my reach and control.
