[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Move from CVSNT to SVN?

From: Ryan Schmidt <subversion-2009b_at_ryandesign.com>
Date: Thu, 10 Sep 2009 16:21:39 -0500

On Sep 10, 2009, at 10:19, Eric B. wrote:

> With respect to the repository, I am a little confused about a few
> things. I know that SVN was originally designed to run off a db.
> However, I know it now does flat files as well. Is the flat file
> structure not akin to a CVS repository? Has there been any further
> progress or development to support DBs other than BDB? Do you know
> if there is a particular reason why BDB was chosen vs something like
> MySQL?

A Subversion repository is stored in a database. In Subversion 1.0 and
earlier, that was always a BerkeleyDB database. In Subversion 1.1, it
became possible to use a flat-file database instead. This flat-file
database format is called FSFS and was designed especially for use by
Subversion to work around some of the issues that existed when using
BDB with Subversion. FSFS became the default for new repositories in
Subversion 1.2 and still is today, and works great. No other backend
storage options are available. What advantage do you believe would be
gained by using another backend such as MySQL?

The FSFS Subversion repository storage format is not like the CVS
repository storage format. In CVS, there is one database file per
versioned file (each containing many revisions of a single versioned
file). But in Subversion's FSFS, there are two files per revision (one
containing the differences to the contents of all versioned files
affected by the revision, and another containing the properties of all
versioned files and directories affected by the revision).


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-10 23:22:30 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.