My DevOps consulting life (around how to get to Trunk-Based Development from some often ClearCase inspired branching model), starts with what release cadence are you at now, and what do you want to get to. Clients who are quartly want to get to monthly (and have less unplanned releases following each). Clients that are monthly want to get to weekly (same elimination on unplanned). Aaand clients that are weekky eye daily. Sure that's dev teams of 20-1000 in one repo, where change would firehose into the repo if it could,
*I've not encountered an enterprise team that wanted to slow down release cadence.* Seems to me Svn's problems are 1) lack of committers, perhaps because 2) patch contributors don't feel it matches their smoother experience elsewhere, and because 3) running "the build" from zero is hard, and 4) tests in the build isn't a super uniform thing. If you all developed on trunk (patchsets for trunk, or direct to it), and had an automated CI build setup that tested all permutations in parallel, and a merging bot that attempted to cherry-pick commits marked as [BUGFIX] back to all supported release branches without human intervention (and Apache-TM votes), then you might have streamlined things. Such a bot shouldn't shit the bed if the cherry-pick fails * Of course you're stymied by a lack of a integrated patch consumption technology. Gerrit and Rietveld were made in Mondrian's image, ten years ago. That said GitHub and pull requests a few months later stole the spotlight and have not relinquished it since. Julian's stash/shelve tech is the start of a standardized Pull-Request system for Svn, but the vision need to be expanded. Meanwhile, Mononoke ** is pushing forward to monorepo-nirvana even if Atlassian today declare that Mercurial support in BitBucket has an end date. * oh, the back-applying merge bot will work fine as long as no rename/move refactorings happen in the Subversion tree. That's because Subversion can't merge through rename (unlike Git and Mercurial - seamless). Perforce could do it if you muck around with branch-specs, but nobody does. ** Mononoke (a Rust backend for Mercurial) is hosted on GitHub (Git). The dev eam feels no shame from that, perhaps because it's a periodical copy from the same source-tree inside Facebook (and isn't currently buildable). Git made a Svn compatibility for GitHub's Git repos - I wonder if future contributors to Mononoke could too. Repo: https://github.com/facebookexperimental/mononoke
