On Fri, Jul 5, 2024 at 9:29 AM Nathan Hartman <hartman.nat...@gmail.com> wrote:
> On Fri, Jul 5, 2024 at 6:59 AM Daniel Sahlberg < > daniel.l.sahlb...@gmail.com> wrote: > >> Den fre 5 juli 2024 kl 12:44 skrev Roshan Pardeshi < >> roshan.parde...@ncdex.com>: >> >>> Hello Nathan/ Team, >>> >>> Waitng for your revert on trail nail. >>> >> >> The short answer is that you can't decrease the disk usage from the >> repository. The repository is immutable and you can't change history. >> >> A branch is in general quite lightweight and only stores the information >> that has changed in that particular branch so I'm not sure exactly how much >> data you will save by deleting old branches. >> >> If you REALLY need to remove things, you could use `svnrdump` or >> `svnadmin dump` with the --include/--exclude options to only dump the >> revisions/paths you want to keep. Then you load the dumpfle to a new >> repository using `svnadmin load` (you should use the --ignore-uuid option >> when loading). When you do this, all existing working copies will be >> invalid and the users need to check out new working copies. >> >> Please check the help texts for more information. >> >> Kind regards, >> Daniel >> > The "svnadmin dump" approach requires shell access on the primary server. If you *can*, setting up svnsync to a second server to get a working and maintainable, up-to-date copy to attempt dumps and pruning operations from. It can get *expensive* to set up such spaces with an oversized repository, and be quite impossible to complete the initial svnsync operation, as it is impossible to complete for the primary subversion repo for subversion itself.
