You're asking how to implement a generic rewrite of a historical revision, but aren't addressing the question of what to do with younger-than-the- rename revisions that do not apply (in the libsvn_delta, libsvn_diff, or tree-delta sense) to the modified history.
If you're serious about solving this problem I strongly suggest that you talk to Julian. I think he went up and down this path so much that he can tell the squirrels' furs' colors from hearing. On Sunday, November 27, 2011 11:16 PM, "Johan Corveleyn" <jcor...@gmail.com> wrote: > <wild idea> > What if we could 'svnadmin (re)load' a single revision $REV in a > repository, which would then automatically fix up everything coming > after $REV: > > 0. Take backup > 1. Dump $REV > 2. Fix $REV.dumpfile with some dumptool > 3. Take repo offline > 4. Reload $REV (fixes up everything after $REV) > 5. Bring repo back online > > For the part of "... automatically fix up everything coming after $REV": > > - naive approach: simply dump+load internally in the repository > ("reload") everything from $REV+1 until HEAD. > > - better approaches may be possible, depending on the change that > was done in $REV, and depending on the type of backend. > > Of course this reloading step will be more costly if $REV is far > before HEAD, but that's normal I guess. If you are able to fix > problems not too late after they happened, the reloading cost will be > reasonable. > </wild idea> > > Thoughts? > > -- > Johan >