Palmin's questions

I have an svn dump file which includes "empty" revisions (these were created by svnsync when synching only a subdirectory of an existing repository).

Since I'd like to use the svnsync'd repository as the new master (no need to sync again), I wanted to get rid of all the empty revisions.

Unfortunately, running the dump through svndumpfilter does not seem to remove the empty revisions, probably because svndumpfilter only looks at revisions it cleaned up by itself with the --exclude option (see also here)

I was also looking into svndumptool, but it does not seem to provide this functionality.

Is it possible to filter these revisions in any other way?

I have the task of extracting a subdirectory of a subversion (1.6) repository and place it into a new repository of its own.

For several reasons I wanted to use svnsync to replicate the subdirectory into a new repository. I now want to make sure that this is safe, because the SVNBook says (subversion 1.5)

svnsync is very sensitive to changes made in the mirror repository that weren't made as part of a mirroring operation. To prevent this from happening, it's best if the svnsync process is the only process permitted to modify the mirror repository.

and (subversion 1.6)

Warning

Do not modify a mirror repository in such a way as to cause its version history to deviate from that of the repository it mirrors. The only commits and revision property modifications that ever occur on that mirror repository should be those performed by the svnsync tool.

I am assuming that this is valid if you want to use svnsync to actually keep a mirror up-to-date.

Our use-case is

1. svnsync a subdirectory of repository A to repository B
2. Make subdirectory of repository A read-only (only for archival purposes)
3. Make all further commits of the content on repository B

Can anyone confirm that this use-case is feasible?

I have a server system running on Mac OS X 10.4 (Darwin Kernel Version 8.10.1). This server is used mainly as a Bugzilla Server, but there are some other web-based services running (Testlink, TikiWiki).

The Bugzilla database has about 60000 bugs in it, and there are about 300 active users on the system.

Bugzilla is on version 3.0, running on Perl 5.8.6, Apache 1.3.33 with mySQL 5.0.38

From time to time, we have serious trouble that Bugzilla throws a database error:

Software error:

Can't connect to the database.
Error: Too many connections

I already have several leads to possible solutions to this problem, but I wanted to bring up a more general question how you would debug these types of problems?

Right now we have set up the following to monitor the mySQL database:

• A cron job which dumps the full mysql processlist every 5 minutes
• Enabled log-slow-queries in my.cnf to log queries that take longer than 15 seconds

We just started gathering this data to see if we can find a reason for the "Too many connections" problem.

Are there any other things you can think of to monitor a mySQL database and to help diagnose the root cause of the problem?