First, Great email list, full of fast answers and very useful
information.
I have been reading it for a while familiarizing myself with subversion.
My company is looking at moving from a proprietary repository system and
using subversion. Our code base is very large, there will probably be
around 80k files plus 1-2k in binary files, all of which take up 12G
with a checkout from HEAD. Fortunately, everything is already divided
into projects so I can split it up into different repositories or
systems. We will have 300 users continuously accessing the repository 8
hours a day so performance is of great concern. We will be designing a
tracking tool that will store its data in a relational DB. The tracking
tool will need to access metadata (mainly versioned properties)
regularly.
So which backend is prefferred now, and which do you all, the users and
developers see as the future for subversion? I have read the online
book, browsed this list and googled on the subject. From what I have
seen bdb seems to suffer from locking problems due to lost connections
and db corruptions among other things. Few have encountered problems
with fsfs however it hasnt been quite as proven. bdb can allow third
party apps to access the db backend and read metadata for our tracking
tool (primarily for searching). There appears to be no equivalent
methodology for fsfs. Given the file format, one may not be that hard to
write though I suppose, but there is a locking issue. For our
implementation, we need to decide on the backend first, switching later
is not an option without a rewrite of our (future) tracking tool's svn
API.
fsfs is what I am leaning towards now for stability reasons. Are there
other backends in development? Can bdb be sucessfully run with a project
of this size? If a db gets corrupted, 200 people are instantly locked
out of the repository. Backing up and restoring can take a lot time and
money (200 people x 30 minutes = tens of thousands of dollars).
Thanks for your time,
Brad
Received on Thu Jan 13 17:36:48 2005