On Fri, Dec 19, 2025 at 9:32 AM Craig Russell <[email protected]> wrote:
> > On Dec 18, 2025, at 18:02, Greg Stein <[email protected]> wrote: > > > > Because the svn-based solution is hitting operational snags. It MUST be > > replaced. > > > > svn itself has no problem with a repository measured in dozens of > > terabytes. But that totally blows up operational concerns. > > Last I heard (and I do pay attention) svn is where the projects put their > stuff. After that, infra makes dozens of copies and distributes them around > the world and delivers them via dyn/closer and/or dlcdn. Svn does not have > to scale. Read what I wrote. svn scales just fine. That is NOT the problem. Trying to backup dozens of terabytes, or to copy them to a new machine ... that is the *operational* concern of such a massive svn repository. Not svn itself. Compare trying to manage (1) 40T file (an svn repository is many files, but logically must be considered as a single file; much like we look at a single file being composed as many sectors on a hard drive), compared to managing 100,000 files, each at 400M. ... The latter is much easier. You can thing up. Spread them out. Copy little bits at a time. So many more options. Serving the artifacts can become easier because of serving off disk, rather than via mod_dav_svn. (we serve off disk, actually, but that requires svnwcsub which introduces its own set of synchronization problems). Throw in an rsync service to just keep things toasty. Dave says there is something related to security, but I'm not buying that whatsoever. svn has fine-grained permissions, which is implemented for repos/dist/, so I don't know what he's talking about. Maybe he should ask an svn expert. Regards, -g
