Yonik pointed out on #lucene-dev IRC <http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-07-12#l356> that SVN history for trunk/solr/ seems to be borked following my SOLR-2452 commit.
AFAICT, I caused this problem by using "svn merge --reintegrate https://svn.apache.org/repos/asf/lucene/branches/solr2452"; to transfer the SOLR-2452 changes to trunk. I had thought that this method would preserve trunk history better than other available options. I was wrong. I now think that for mass restructuring, rather than a dedicated branch, it's better to keep the changes as an svn movement script and a patch, even though this requires regular "svn diff >../my.patch ; svn --recursive revert . ; svn update ; patch -p0 <../my.patch" cycles to keep up with concurrent development. Here's how I'd like to fix the problem: 1. Backport to branch_3x by re-creating the SOLR-2452 changes as an svn movement script + patch (this is underway now), applying them, then committing. At this point, trunk and branch_3x will be in sync and devs can get back to normal backporting procedure. branch_3x won't suffer the same history problem as trunk. 2. Create a "newtrunk" branch (with solr2452 in the name somehow), copying from trunk at the revision just before SOLR-2452 was committed. 3. Convert all SOLR-2452 changes into a single svn movement script + patch, then apply them to "newtrunk" and commit. At this point, the structure and content of the "newtrunk" branch should be identical to trunk right after the SOLR-2452 commit, except for history-tracking svn properties. 4. Merge to "newtrunk" each commit applied to trunk since SOLR-2452 was committed to trunk, and commit each with the original log message. 5. svn rm trunk ; svn mv newtrunk trunk (with URLs, not WC paths) The disadvantages I can think of to using the above approach: a) the post-2452 re-commits (#4 above) will be recorded as committed by me instead of the original committer; and b) the large amount of work required to make it happen (I think it will be worth it though - I'm a big fan of SVN history.) The main advantage to this approach is that development can proceed normally. The only dev pain, AFAIK, will be the need to re-checkout after the process is complete. Thoughts? Steve
