79

In our project we made the decision to reduce the build time by using pre-built binaries. Weekly/monthly we create a stable release and commit it to the repository. The build uses these binaries instead of building everything from source.

For build speed this is fantastic. But, unsurprisingly, it really bulks up the SVN checkout size. Our trunk currently sits at ~22 GB. I realize this is not the intended usage of Subversion. But we don't have an alternative at the moment.

But I'd like to improve the current situation. The .svn folder makes a big contribution to the size of trunk on disk. When the binaries are updated, it seems to keep several bases in the .svn folder. That is, if a binary is 4 GB there is a copy in the .svn. If it's updated then the .svn folder holds the original base plus the new base and bulks up to 8 GB for that one file.

Is it possible to tell Subversion not to keep a base in the .svn folder for certain files? Through google I found a similar question, How to decrease .svn folder size?.

The answer Simon received was

  • Use a partial checkout (which won't work for me as I need the binaries)
  • This is not yet a feature of Subversion
  • It was discussed, but will not be a feature until at least Subversion 1.8

Luckily for me subversion 1.8 has been released. Was this feature added?

I did not notice it in the release notes. Though "Directory and property storage reduction" looks promising.

Zoe
  • 27,060
  • 21
  • 118
  • 148
Shane Gannon
  • 6,770
  • 7
  • 41
  • 64
  • 1
    This is not really where subversion shines - you should look into artifactory or nexus to store the artifacts and resolve (fetch) them with your build script. – thekbb Jan 09 '14 at 20:25
  • Sadly we knew this. But its just so convenient to use svn. In the past, on another project, we employed Maven. But, apparently, that left a bad taste in a lot of peoples mouth. Next came a custom tool that I can only describe as Maven like (but which, of course, solved all Maven's problems). That too left a bad taste. In our latest project we just ended up leveraging svn. – Shane Gannon Jan 09 '14 at 20:45

2 Answers2

77

There's no way to get rid of the need to store pristines at this point. It's been talked about but it's actually not an easy problem to solve because there's so many different use case situations that would be presented by removing them optionally.

With 1.7 the pristine storage was changed and in some cases you may actually see the situation as worse than before 1.7. Pristines are now stored in files named by the hash of the pristine. So if you have multiple identical files you won't have duplicate pristines stored. However, we also don't cleanup pristines anymore. So they just continue to build up. You can trigger unused pristines to be removed with svn cleanup.

There is a point to keeping unused pristines around, if you're switching between branches we no longer have to download things that you already have the pristine for in 1.8.

Ben Reser
  • 5,695
  • 1
  • 21
  • 29
  • Thanks Ben. I suspected this would be the answer. But I hoped otherwise I suppose. The svn cleanup tip is handy to know. We conjecture that it might remove the extra pristine(s) but had not yet tested. I like that an md5 is used to keep only unique copies. But not removing old copies "seems" incorrect. Branch switching is a scenario this behavior supports. But I "suspect" that more often the old pristine will never be used again. i.e. It will just suck up disk space. While our, unrecommended, usage of svn makes this a noticeable con I think it also applies to normal projects. – Shane Gannon Jan 09 '14 at 21:01
  • We agree, there's an issue open on this: http://subversion.tigris.org/issues/show_bug.cgi?id=4071 – Ben Reser Jan 09 '14 at 22:03
  • 2
    That's great, together with [svn update --set-depth=exclude](http://stackoverflow.com/a/8446590/1904815) this saved me 12 GiB. – JonnyJD Apr 28 '15 at 19:49
  • 8
    Wow just saved 21GB space using svn cleanup. Thanks a lot! – NoAngel Dec 25 '15 at 05:40
  • I had erased tons of build artifacts that should never have made it into version control and was wondering why the windows explorer still reported ~4GB folder size... a cleanup pristines run left me with ~70MB of actually useful files :) – grek40 Sep 11 '20 at 06:37
48

For those using TortoiseSVN client's Cleanup command rather than svn cleanup command, .svn folders size can be decreased by making sure that Vacuum pristine copies option is checked:

enter image description here

Also, it is recommended to cleanup at the top level of the working copy, as indicated here.

[Edit]

According to this answer and SVN change log, svn cleanup has an option to vacuum pristine copies (/vacuum). This is done by default starting from 1.8. From version 1.10 up it is not longer done by default, but can be run using the command svn cleanup --vacuum-pristines (see this answer).

Xcodo
  • 137
  • 8
Alexei - check Codidact
  • 22,016
  • 16
  • 145
  • 164