On 2026-03-11, Peter G. <[email protected]> wrote: > > that's not the issue. the issue is not to process the same requests > twice. process once, keep in cache, sever instantly without processing. > > this is how a very IO intensive systems usually work. you preload all > caches and serve only from caches. sometimes preloading runs for a > longer while, simply loading caches. then all that content is server > effortlessly without much load.
that's fine if the requests are all the same and the dataset doesn't change often. that is not the case here, there are ~700k files in /cvs, each with many commits that could be diffed, and abusive requests cover a lot of them. > the problem is here a very particular kind of zeal and denial, not > necessarily Nick's, but one in general. note some of the response in the > cvs thread, "because we used it for 29 years", "because here we do > things differently", "because this is what we want" so far there hasn't been anything that meets requirements like "needs to be suitable to include in base and works on supported architectures" and "fits into developer workflow" and that has been enough to go through the significant pain of converting the repo. (I have tried all the conversion tools I can find and afaict the only way to do a proper conversion of the history is to manually recreate tags/branches; every tool that tries to do this from the RCS files fails). > this. the problem is also nonsensical. people scream "but we love CVS, > we used it for 29 years, we are never giving it up" no they don't. however: cvs is not a moving target, we know where the problematic areas are, and afaik no new problems introduced since 2017. with something else there's a higher chance of new surprises. > but then at the same > time they say "all them links we had active for a decade dead? no > problem eh" yes it's not ideal, but think about how the content on cvsweb is used and who is going to be using it, this is not as big an issue as you and cnst think it is. people who can't figure out the new URL are unlikely to be able to make much use of the content anyway. > the dark truth is this: > > 1. OpenBSD needs to move onto a better version control system, ideally > one with very high performing web UIs why "very highly performing"? it's no github-level type of access. just needs to be good enough. btw: git certainly isn't high performing on some machines where cvs runs just fine. > 2. the move needs to be smooth. > > instead of wasting time on CVS keep it as it, and start working on a > parallel system to replace it soon. there are existing projects which might sometime be suitable. > Ken can maybe help in Go with the move. go seems not bad for web applications, but it's not going to fly for a vcs to run on all the archs that OpenBSD targets. -- Please keep replies on the mailing list.
