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