Rationale from [~[hidden email]] for checking that commits are the same before/after a core reload, also from SOLR-2705:
bq. I saw in the patch that you've added getIndexversion and getCommits, but haven't used them.
Right - they where good for debugging and I figured I would use them to investigate SOLR-2326.
bq. Can Junit check for indexversion/commits to be same right before and right after coreReload?
I've committed this check.
I don't see how comparing commits before/after reload is providing useful information - as Hoss noted in a comment above in response to [~shalinmangar]'s earlier commit:
bq. ... I'd expect that since there were no pending changes, there's be no need to write a new segment. ...
That seems like a naive assumption given the randomized merge settings – there could easily be background merges in other threads, or the randomized merge scheduler could decide to do an arbitrary/useless merge on commit (IIRC)
I'll attach a patch to remove this check from the test. I'll wait a couple days before committing in case there are objections.