________________________________ From: Nico Kadel-Garcia Sent: Friday, 16 August 2013 21:39 PM To: Geoff Field Cc: Philip Martin; users@subversion.apache.org Subject: Re: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)
Get your legacy material off BDB and onto FSFS, ASAP. At least make sure you have *good* backups and are prepared to lose all that data if you don't. BDB has been, in my experience with much older versions of Subversion and with years of Linux application experience, prone to data corruption from unpredictable and unrecoverable userland events and even the slightest blip of the OS or hardware layer. It has also repeatedly proven impossible to upgrade existing data sets to new BDB releases in place. Subversion fortunately has a workable backup system to provide data transfers: I've seen BDB systems that did not. Thanks for the opinion Nico. I'm in the middle of doing the translation now. As I said, though, we have about 100 repositories, most of them in BDB format, so it's no small task. The servers are backed up nightly using IBM's Tivoli Storage Manager. I've had to recover repositories a few times using that tool, so I know it works for us. BDB has never been my friend. We've had a few corrupt repositories over the years. We got to the stage where we wrote an internal Wiki page on fixing corrupt repositories. We had a colleague write an application to help with management of the repos. Unfortunately, he chose to create them in BDB format. That's why we have so many BDB repositories. Rather than recreate the build environment and rebuild the management application, I've edited the EXE file to replace the (DBCS) string that sets the format with spaces. Geoff On Fri, Aug 16, 2013 at 2:13 AM, Geoff Field wrote: > From: Geoff Field > Sent: Friday, 16 August 2013 11:56 AM > Thanks to everybody for their patience with my issue. The > root cause is not really solved, but at least I (and my > colleagues) can get back to normal work patterns. > > I've finally managed to get the upgrade to Apache 2.2 and SVN > server 1.6.9 running. As it turns out, my former colleagues > had deliberately configured all the ports one up from the > default (thus, SSL was running on port 444 instead of the > default 443). Once I'd fixed this, Apache 2.2 started > serving SVN via the default interfaces. > > With that, I can now run everything happily. It seems I spoke too soon. It turns out that the updated SVN server 1.6.9 works for those few of our repositories that are in FSFS format. Unfortunately, our legacy repositories are almost all in BDB format and I'm loathe to touch them if I can avoid it. Building SVN from source is not really a useful option, but we can do it (with a struggle) if we absolutely have to. Frankly, I'd rather convert all the repositories (and there are 100 all up, although some are in FSFS format already) than build the server code. Has anybody built a version that handles BDB in a DAV module? > I have not deleted the Apache 2.0/SVN server 1.2.3 > configuration, so I should be able to switch back to that if > needed. I suppose it's possible some repositories might > become inaccessible to the earlier server due to the server > upgrade, but I'm not particularly fussed about that. We can swap back to the other version fairly easily if we have to, just by stopping Apache2.2 and starting Apache2 (or vice-versa). Regards, Geoff - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
