Over the years our SVN repo has grown to around 100Gb in the local copies. As roughly 1/2 of this is in the .svn folder I surmise a chunk of the space is in the history. Whilst the history is useful its not required most of the time.

I have space on the server to make a copy of the repo 'frozen' at now, thus keeping the history upto now, and then make a fresh copy of the repo from the HEAD to start again.

By placing the frozen repo at a new url I hoped to put the minified repo back at the same url and not have to go around all the users to get a fresh checkout. I was hoping that an update would just pull the minification into the existing working copies. (and also thus avoid potential for losing uncommitted work). After creating a copy of the repo to be frozen I have tried a dump of only HEAD:

svnadmin dump myRepo -r HEAD > my.dump

then deleting the existing repo and loading the head only dump in:

svnadmin load myRepo --file my.dump

The repo shrinks to around 60Gb disk space used - I also took the opportunity to remove some stuff which we wont need going forward, but is left in the frozen repo 'in case'.

The fresh repo of course is at revision 1, whereas the working copies from the now frozen one are at revision (around) 9000. As a result my plan of 'just' doing an update fails with an error.

Looking around it seems that the normal way around this is to create 9000 odd empty commmits to make the numbers match and then it should work ok. That seems a bit of a bodge. Would that work?

Given I was trying to lose the history to save space it will create a load of history I dont need. Are empty commits tiny?

Is there a work around, or is the best recourse just to accept the need to do a fresh checkout on all the machines?