On 09.03.2005, at 19:55, Craig A. Vanderborgh wrote:
> I am currently stuck on the issue of which repository type to use -
> Berkeley or Flat Filesystem. Our use case has the following (somewhat
> unusual) features:
>
> 0. Long-term "bullet proof" operation is the primary need - all other
> considerations are secondary.
> 1. The repositories will be large - about the size of Linux kernel
> source trees.
> 2. The commits to the repositories will be fairly infrequent.
> 3. Merge conflicts will be relatively rare
> 4. Speed of working area population is of paramount importance
>
> So, based on these factors I've concluded that Flat Filesystem is the
> better choice for us. Does this seem right? [...]
We decided on FSFS over BDB because I didn't like the frequency with
which people were reporting BDB errors on this mailing list, and I had
yet to see any reports of similar problems with the FSFS backend. Mind
you, the FSFS backend is newer, therefore less tested in real-world
situations, but considering a choice between an old known-problematic
setup and a new setup for which I have so far not seen any problem
reports, I chose the latter, and we've had no problems in our first
month.
One way to bullet-proof the thing is to write a post-commit hook which
does an svndump to record the changes made in that revision, saving
each new svndump to its own file (with a name based on the revision
number). Even if the repository goes completely bananas some day and
destroys itself, you'll have up-to-the-minute dumps of every revision
that you can re-import in order into a new repository. This was
suggested by someone on the list recently, I just don't remember when,
but it'll be in the archives. There may have been a script attached,
but writing such a post-commit hook yourself should be easy.
You could also create a backup daily, or at some other interval, with a
script like the one posted to the list here in January:
http://svn.haxx.se/users/archive-2005-01/1779.shtml
Checking out a working copy from our repository does not seem
particularly speedy to me, but I have no reference point for
comparison, and it's not really really slow either. It depends on your
server's horsepower, to be sure, but we are also using Apache 2, which
I've heard is slower than svnserve. We opted for Apache because we're
already familiar with it (we're a web development shop) and because it
just generally gave us a warm fuzzy feeling. But if checking out or
updating a working copy needs to be superfast, investigate svnserve,
making sure to observe the caveats about filesystem permissions and
ownership explained in the book.
Good luck.
\r
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 10 19:43:20 2005