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" <jcorvel_at_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
>
Received on 2011-11-28 07:33:00 CET