So instead of adding an init param version of numberToKeep, perhaps it owuld be better if the "backupAfter" codepath followed the same code path as handleRequest as much as possible?
It wasn't so much my intention to add an init-param but to make a way to give a default value for this in solrconfig.xml as you can for other handlers. Without a way to declare a default in solrconfig.xml, the user has no way to use this parameter should a backup be triggered by "backupAfter".
When I looked at this, it didn't seem that ReplicationHandler follows the normal rules. We don't have a <defaults /> section for request parameters, do we? And looking at the available request parameters, we probably wouldn't want defaults for any of them (see http://wiki.apache.org/solr/SolrReplication#HTTP_API).
This makes me wonder if my first try was a mistake. Possibly this should only be an init-param. This would let users configure how many to keep on the Master, and how many to keep on the Slave. We don't let users change poll intervals with request params, so why let them change the archive policy with request params?
If we kept it as a request-param only, but then let the user specify defaults, would that create a legal <defaults /> and <invariants /> section nested within <master /> and <slave />, so users can specify defaults for each?
I don't have a strong feeling on this and would change the patch to work any way you thought best. Somehow it seems that "numberToKeep" needs to have a default setting somewhere, somehow, so it will work with "backupAfter".