Subversion repository filesystems

Karl

Karl

Karl

Soldato
Joined
23 Oct 2002
Posts
4,152
Location
_
I'm looking at installing a repository on a remote server (It's also firewalled and I'll be getting a domain to point to it).

The gets and updates will be via HTTP as a result, and I wondered who's had any success with BerkeleyDB vs FSFS in this circumstances?

It doesn't appear that there's any default, and I'm a bit stuck!

Cheers,

Karl.
 
From: http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.reposadmin.basics.backends

There are advantages and disadvantages to each of these two back-end types. Neither of them is more “official” than the other, though the newer FSFS is the default data store as of Subversion 1.2. Both are reliable enough to trust with your versioned data. But as you can see in Table 5.1, “Repository Data Store Comparison”, the FSFS backend provides quite a bit more flexibility in terms of its supported deployment scenarios. More flexibility means you have to work a little harder to find ways to deploy it incorrectly. Those reasons—plus the fact that not using Berkeley DB means there's one fewer component in the system—largely explain why today almost everyone uses the FSFS backend when creating new repositories.
Fortunately, most programs which access Subversion repositories are blissfully ignorant of which back-end data store is in use. And you aren't even necessarily stuck with your first choice of a data store—in the event that you change your mind later, Subversion provides ways of migrating your repository's data into another repository that uses a different back-end data store. We talk more about that later in this chapter.
Click to expand...

From the FSFS section:
The only real argument against FSFS is its relative immaturity compared to Berkeley DB. Unlike Berkeley DB, which has years of history, its own dedicated development team and, now, Oracle's mighty name attached to it, [31] FSFS is a much newer bit of engineering. Prior to Subversion 1.4, it was still shaking out some pretty serious data integrity bugs which, while only triggered in very rare cases, nonetheless did occur. That said, FSFS has quickly become the back-end of choice for some of the largest public and private Subversion repositories, and promises a lower barrier to entry for Subversion across the board.
Click to expand...
 
Bear in mind that you can access a remote SVN repository with SSH:
Code: 
svn co svn+ssh://user@host/path/to/repo
Which would negate the need for Apache/IIS, unless you specifically need the web/HTTP interface of course.
 
You must log in or register to reply here.
Back
Top Bottom