Johan Corveleyn wrote on Mon, Nov 28, 2011 at 21:37:43 +0100:
> On Mon, Nov 28, 2011 at 7:32 AM, Daniel Shahaf <d...@daniel.shahaf.name>
> wrote:
> > 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
> >>
> > 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
I meant s/rename/reload/.
> > tree-delta sense) to the modified history.
>
> I'm not sure I understand. If all those younger-than-the-rename
> revisions are "reloaded", there wouldn't be a problem, right? Ok,
> maybe some of them don't need to be touched in any way, because they
> do not apply to the modified history, but that can be seen as an
> optimization, right?
>
I was thinking about the general case: replacing a revision X by an
arbitrarily-different revision.
In the special case of just updating the copyfrom pointers file contents
obviously wouldn't be affected, and if the younger-than-the-reload
revisions are replayed (in the svn_ra_replay*() sense) then they would
be okay too... but if we try to use the tree merge logic on them (why?
again, for the general-rewrite case) then I think the changing of
copyfrom link may have visible consequences --- for example, since 'svn
merge' takes a --ignore-ancestry option.
> It's actually a bit similar to your suggestion of 'svnsync
> --up-to-revision', which you made elsethread. But with dump/load, and
> wrapped into a convenient tool for an svn administrator.
> Concerning the question "if I'm serious about solving this problem":
> well, at this point it's really only an academic exercise, trying to
> find a way which works in theory. I'm not sure if I'm serious about
> implementing this myself (at my current rate (of free time x speed)
> that might take me several years, and I'm not sure that's worth it for
> my personal situation). So I guess at this point I'm just throwing
> around some ideas, hoping that some good will come out of it, and that
> someone will one day write the code to do it :-).
>
Fair enough, thanks for clarifying :)
> --
> Johan
