> On Dec 19, 2025, at 16:53, Greg Stein <[email protected]> wrote: > > On Fri, Dec 19, 2025 at 9:32 AM Craig Russell <[email protected] > <mailto:[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. There are two aspects of scalability that might be relevant here. 1. Volume of requests to the repository. This is apparently solved by having dyn/closer and dlcdn serving artifacts distributed around the world. 2. Size of the repository. If the entire dist repository is in one file, that's a recipe for infra overload. An alternative is that without changing the external view of the repo, each of the subdirectories could be its own svn repository. That would cut down the size of the dist repo to 1% of its current size. Of course, changing the structure of dist would impact anyone who has the repo checked out to a local copy, but... Craig > > 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 Craig L Russell [email protected]
