4

I'm planning on setting up an svn repository which will contain 3rd party binaries that various product builds at my work place will depend on. since these are all binaries and not text files any addition to this repository will duplicate the artifacts and i'm a bit concerned about size limit.

right now i'm looking at ~15 GB of binaries, and i know 350GB is possible (as evident from this question - 350GB SVN repo creates atleast 1MB revision for even a simplest task like branch/tag).

i also know there are limitations imposed by the underlying operating system (2GB max singel file size for example, which i dont expect to hit), and there's no hard limit in the svn code.

what im asking is how large have people seen svn get without major issues? also keep in mind this repository will be (relatively) seldomly updated - about once every few weeks.

my options for operating systems are windows x64 (server 2008, most probably) and linux x64 (probably red hat ent.). file systems will be ntfs in windows and whatever i want on linux.

clients will mostly be tortoise svn 1.7

so what are the practical limits in my case?

Community
  • 1
  • 1
radai
  • 23,949
  • 10
  • 71
  • 115
  • "since these are all binary blobs" - Rewind. Say what? – Mitch Wheat Feb 06 '13 at 08:23
  • i meant i'll be storing a lot of non-text artifacts there (*.dll, *.so, *.zip, etc) so i expect the size to grow quickly – radai Feb 06 '13 at 08:36
  • 2
    Why are you planning on storing binaries in svn? There are potentially other solutions than svn which may be more appropriate. – MrsTang Feb 06 '13 at 08:38
  • its actually a bit more complex. the "long term storage" (as in backed up and safe) will be svn, but artifacts from this svn will be deployed to nexus, and thats where the builds that need them will pick them up from. – radai Feb 06 '13 at 08:42
  • Subversion is not a backup system, so please don't use it as such. Keep these libraries in another store of some sort (or even a separate SVN repository, and reference via externals) and pull them in as part of your build & distribution process. – alroc Feb 06 '13 at 14:42
  • no, but it is very good at keeping track of who changed what, when and why, which things like nexus arent really built for – radai Feb 06 '13 at 19:36

1 Answers1

4

First of all, Subversion is a modern version control system, so binary data as such isn't an issue. Subversion can create deltas from binary data, so the commits will be as small as possible.

The problem is usually that binary data actively prevents to generate small deltas. One reason is that binary data can be compressed and that usually causes huge differences.

That said, your repo probably won't grow extremely fast anyway. We have a big product which currently uses about 400 third party dependencies. Every month, a couple of those change. Or to put it another way: Your dependencies won't all change every week. That means you will only add a few MB per month (unless you have a really unstable dependency which changes a lot but again, most dependencies aren't like that).

So my gut feeling is just to try it and solve any problems as they show up because there probably won't be any big/unusable problems anyway.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820