"Frank Striegel" <f.striegel@easysoft.info> wrote:
> Hallo,
>
> have anyone had any problems with a svn repository as native file system
> (FSFS)?
>
> Thanks.
>
> Frank
I've had lots of small subversion repositories with fsfs and have had
no negative issues at all. I've had no functionality problems on a
big repository and have had some minor performance issues, but nothing
that makes me not want to use it. Here are some details.
I've done a couple of dry runs on converting my 9-year-old > 1GB CVS
repository to subversion using cvs2svn. The conversion to an fsfs
subversion repository went fine and resulted in a repository just a
hair smaller than the original CVS repository. (The bdb version I had
tried earlier was more than three times larger than the CVS
repository.) All my access so far as been to my local disk. My
machine is a 2.4 GHz Pentium 4 with 1 GB RAM. The repository is on an
ATA133 drive with an XFS file system. I'm running Debian sid with a
2.4.27 kernel.
The resulting subversion repository has 22,026 revisions including
close to 300 branches and well over 2,000 tags. cvs2svn created a
very reasonable repository from my CVS repository, which is very
orderly. For an fsfs repository of this size and this number of
revisions, the time delay in checking out the latest revision of some
files is noticeably slower than with CVS, but all in all, it seems
fine and wouldn't make much of a difference under most conditions.
The file with the most revisions has 132 revisions. With no files
cached by the OS (e.g. after unmounting and remounting the drive with
the repository), it takes about 1.5 seconds to check out the latest
revision of this file. Using CVS, it's virtually instantaneous. (Of
course, CVS stores the latest revision intact on the history file and
generates diffs going backwards, while svn with fsfs has to
reconstruct the file from all its revisions. This is why I did this
test.) Checking the entire 1 GB repository's trunk took 14 minutes.
Checking out the entire repository from CVS took a little over 4
minutes.
While accessing the repository from the local file system, a command
like svn ls file:///..../tags can take close to a minute to run on my
machine. Of course, with CVS, there would be no quick way to get a
list of all the tags to begin with. Running svn log on the trunk
takes over six minutes, which means it goes through about 60 revisions
per second. (Of course, subsequent runs are faster as files are
cached.) This seems pretty reasonable. Running svn log on a
directory with hundreds of revisions is just fine -- it also seems to
go about 60 revisions per second on my machine. Performance of svn
diff between branchpoint and branches is also quite reasonable.
I'm on the verge of switching to this for production use, but I have
some tools that know our repository is CVS-based (like our release
system), so I have a little more work to do first....
--
Jay Berkenbilt <ejb@ql.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 31 19:26:17 2005