Best practise for long term repository size management

Greetings,

  I've taken the approach of One Big Repository (OBR), in
  order to be able to happily copy code between projects
  and retain some history (and perhaps, be able to merge
  changes back).

  However, this has led me to think that I may have created
  a bit of a size beast.

  Currently, with around 10-15 people actively using the
  repository, it's growing at the rate of around 20M/day.
  The reason for this is mostly the kind of files being used
  (large Word docs are the main culprit), but I only expect
  this rate of growth to increase as more users come online.

  Without the ability to "prune" out old data, I fear an
  impending point where the database is too large to backup,
  and most of the data within it is unchanging historical
  data anyway. The database also becomes difficult to manage
  (i.e. takes significant time to copy, etc) if the size becomes
  too large.

  I guess the tradeoff is between database size and amount
  of history retained, but some guidance as to the point at
  which you draw the line would be useful.

  My questions are:

    1) Should the OBR approach be discouraged, for the reason
       that it may grow to unmanageable volumes?
    2) Is there any reasonable way to archive and prune
       unused historical data? (Perhaps "svn obliterate"
       will solve this)....

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 09:48:27 2003