Hi,
I'm planning to upgrade an old public/internal development infrastructure and will use CentOS 5.4 x86_64 as basis.
One of the critical server is Subversion (as an Apache httpd module). We currently use Subversion v1.4 on the server and v1.6 on our clients.
While I was very happy with the v1.4 server over the years, we now sometimes have weird issues which seem related to compatibility with the v1.6 clients (typically working copy depth related). I also want to take the chance of this major overhaul of our infrastructure (and related testing etc.) to upgrade the various components and I'll be happy to benefit from Subversion improvements on the server side as well (especially if it then the version in production for another few years).
The Subversion version in CentOS 5.4 is v1.4, whereas RPMForge provides v1.6. I use the RPMForge version as my client on the desktop.
- Has anyone of you experience running Subversion servers on CentOS? - Would you in general consider as less secure / safe / stable to use RPMForge packages for such critical tasks?
Thanks in advance for your thoughts!
Mathieu
On Tue, 2009-12-15 at 10:22 +0100, Mathieu Baudier wrote:
Hi,
I'm planning to upgrade an old public/internal development infrastructure and will use CentOS 5.4 x86_64 as basis.
One of the critical server is Subversion (as an Apache httpd module). We currently use Subversion v1.4 on the server and v1.6 on our clients.
While I was very happy with the v1.4 server over the years, we now sometimes have weird issues which seem related to compatibility with the v1.6 clients (typically working copy depth related). I also want to take the chance of this major overhaul of our infrastructure (and related testing etc.) to upgrade the various components and I'll be happy to benefit from Subversion improvements on the server side as well (especially if it then the version in production for another few years).
The Subversion version in CentOS 5.4 is v1.4, whereas RPMForge provides v1.6. I use the RPMForge version as my client on the desktop.
- Has anyone of you experience running Subversion servers on CentOS?
- Would you in general consider as less secure / safe / stable to use
RPMForge packages for such critical tasks?
Thanks in advance for your thoughts!
---- I am a lightweight user of SVN
I always use the rpmforge version of svn server
Craig
On 12/15/2009 4:22 AM, Mathieu Baudier wrote:
Hi,
I'm planning to upgrade an old public/internal development infrastructure and will use CentOS 5.4 x86_64 as basis.
The Subversion version in CentOS 5.4 is v1.4, whereas RPMForge provides v1.6. I use the RPMForge version as my client on the desktop.
- Has anyone of you experience running Subversion servers on CentOS?
Yes, when we upgraded to SVN 1.6 on the server, we moved from our old Linux box to CentOS. We did a svn dump/load cycle to move from the 1.4 server to the 1.6 server. And kept the 1.4 dump files for posterity.
- Would you in general consider as less secure / safe / stable to use
RPMForge packages for such critical tasks?
Nope. Works fine. Between the nightly hot-copy backups and the internal design of the SVN FSFS storage engine, I'm not terribly worried.
(We took advantage of repository sharding in 1.6, which is why we did a svn dump/load method. If we didn't need sharding, we probably could've just copied the directory tree across from the 1.4 to the 1.6 server.)
Thanks for your answers!
Nope. Works fine. Between the nightly hot-copy backups and the internal design of the SVN FSFS storage engine, I'm not terribly worried.
I tend to use svnadmin dump for my daily backups. (some time ago, I ran into compatibility issues with hotcopy when trying to restore on a different OS and it kind of frightened me.)
What would make you prefer to use hotcopy rather than dump? Performance?
(We took advantage of repository sharding in 1.6, which is why we did a svn dump/load method. If we didn't need sharding, we probably could've just copied the directory tree across from the 1.4 to the 1.6 server.)
Did you consider the type of filesystem when setting up sharding? Or would you consider ext3 as good enough?
Thanks for your answers!
Nope. Works fine. Between the nightly hot-copy backups and the internal design of the SVN FSFS storage engine, I'm not terribly worried.
I tend to use svnadmin dump for my daily backups. (some time ago, I ran into compatibility issues with hotcopy when trying to restore on a different OS and it kind of frightened me.)
What would make you prefer to use hotcopy rather than dump? Performance?
Inertia. Although we're running all CentOS 5 x86_64, so even if the machine went down, we would have lots of other choices. But I do need to look at using svnadmin dump instead.
(We took advantage of repository sharding in 1.6, which is why we did a svn dump/load method. If we didn't need sharding, we probably could've just copied the directory tree across from the 1.4 to the 1.6 server.)
Did you consider the type of filesystem when setting up sharding? Or would you consider ext3 as good enough?
The only time I have problems with ext3 is with the deletion of large files. The ext3 file system is rather horrid, performance-wise, when you delete lots and lots of files, or a few really big files. I think it's trying to update the list of free blocks / inodes, but I'm not sure.
Since a SVN repository (FSFS style) hardly ever deletes lots of files or large files (except maybe when assembling a 200-400MB check-in?), ext3 is fine for hosting a repository on. The sharding wasn't even really necessary for ext3 with directory indexing turned on, but I decided to play it safe and start sharding to limit the # of rev files in a single folder.
The bigger performance bottlenecks for us are CPU time, and then maybe disk reaction time.
(I did not feel the need to go with packed shards, where all of the revisions get packed into a single file.)
On 12/16/2009 1:32 PM, Mathieu Baudier wrote:
(We took advantage of repository sharding in 1.6, which is why we did a svn dump/load method. If we didn't need sharding, we probably could've just copied the directory tree across from the 1.4 to the 1.6 server.)
Did you consider the type of filesystem when setting up sharding? Or would you consider ext3 as good enough?
One other note on file systems. Our largest repository is 13GB with about 8000 revs. Our repository with the most revs has about 16,000 (but is only a few GB).
So even the 16k rev database probably didn't need sharding yet. But it's growing at the rate of 5-6k revs per year.
-
Craig White -
Mathieu Baudier -
Thomas Harold -
thomas-lists＠nybeta.com