On Thu, Mar 22, 2012 at 9:11 AM, Joel Eidsath <jeidsath_at_gmail.com> wrote:
> I was just handed a large SVN install with thousands of users and
> hundreds of individual repositories. It is experiencing serious
> performance issues. I believe that it mostly boils down to a 14MB
> What can I do to speed this up? Is there a database solution to use
> instead of the flatfile? Can I implement caching somehow? I am willing
> to code something up if I have to.
> Thanks for any help! Please CC me on any replies.
> Joel Eidsath
Copying Dave's reply from an earlier thread this week. Sounds like it would
be really helpful for you:
---------- Forwarded message ----------
> From: David Weintraub <qazwart_at_gmail.com>
> Date: Tue, Mar 20, 2012 at 6:44 PM
> Subject: Re: preventing commits (this is *not* a classic hook question)
> To: michael_at_huettermann.net
> Cc: Bob.Archer_at_amsi.com, lesmikesell_at_gmail.com, nkadel_at_gmail.com,
> I have a pre-commit hook that stores its configuration inside your
> repository. You'll need access to the Subversion server to set it up,
> but once it's setup, you can control access by checking out the
> control file from the repository, making your changes, and then
> checking it back in.
> This is a modification of a hook that I've been using for years.
> Originally, the control file was kept on the server -- usually inside
> the hooks directory. However, that meant logging onto the server, and
> that was getting too difficult to do all the time. Besides, this way,
> I can track who changed the control file and why.
> What prevents anyone from changing the control file? The control file
> is configured, so only the administrators can modify it.
> You can take a look at it at
> https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook. (Yes, a
> Subversion hook is stored in GitHub).
This email, including any attachments, is for the sole use of the intended
recipient and may contain confidential information. If you are not the
intended recipient, please immediately notify us by reply email or by
telephone, delete this email and destroy any copies. Thank you.
Received on 2012-03-22 18:08:57 CET