You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Craig A. Vanderborgh" <cr...@voxware.com> on 2005/03/09 18:55:43 UTC

Berkeley DB versus Flat Filesystem Repositories

Hello,

I'm a Subversion newbie, trying to weave my way through setup issues and 
get a viable Subversion installation working for our organization.

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?  Our server platform is 
x86linux RedHat 8.  I've downloaded and installed the pre-compiled RPMS 
for RH8.  But - is this pre-compiled version Berkeley DB only?  What do 
I have to do to get Flat Filesystem - if this is what I *should* do :^)

Please advise - I'm almost there, but a little bit lost on this BDB vs. 
FFS issue.

Thanks in advance,
craig vanderborgh
voxware incorporated

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Berkeley DB versus Flat Filesystem Repositories

Posted by Andrew Thompson <su...@aktzero.com>.
Craig A. Vanderborgh wrote:
> So, based on these factors I've concluded that Flat Filesystem is the 
> better choice for us.  Does this seem right?  Our server platform is 
> x86linux RedHat 8.  I've downloaded and installed the pre-compiled RPMS 
> for RH8.  But - is this pre-compiled version Berkeley DB only?  What do 
> I have to do to get Flat Filesystem - if this is what I *should* do :^)
> 
> Please advise - I'm almost there, but a little bit lost on this BDB vs. 
> FFS issue.

If you downloaded a 1.1.x version of subversion(*), you should be able 
to choose fsfs.

BDB is the default type if the BDB libraries were installed where 
subversion was compiled.

On my home box, I don't have the BDB libraries, therefore fsfs is 
created by svnadmin by default.

In any case, take a look at the output of: "svnadmin help create" You 
should have an option called fs-type. Read it's description.

Whichever type you decide you want your repositories to be, just 
remember to always specify that when creating them.

-- 
Andrew Thompson
http://aktzero.com/
Interested in hosted SVN repositories? Email me, let's talk...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Berkeley DB versus Flat Filesystem Repositories

Posted by Ryan Schmidt <su...@ryandesign.com>.
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

Re: Berkeley DB versus Flat Filesystem Repositories

Posted by kf...@collab.net.
"Craig A. Vanderborgh" <cr...@voxware.com> writes:
> 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?  Our server platform is
> x86linux RedHat 8.  I've downloaded and installed the pre-compiled
> RPMS for RH8.  But - is this pre-compiled version Berkeley DB only?
> What do I have to do to get Flat Filesystem - if this is what I
> *should* do :^)

Given requirement 0, I think FSFS is right for you.  Not that Berkeley
DB itself has reliability problems, mind you -- but the way Subversion
uses Berkeley DB has some problems, unfortunately, which require more
admin attention to avoid than most people want to put in.  Part of the
reason FSFS was written was to give people an easier option.

By the way, there's a contradiction between 0 and 4.  If 0 is the
primary need, and all other concerns are secondary, then 4 can't be
"paramount" :-).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org