On Mon, Nov 28, 2011 at 7:32 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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
>>
> 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.
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?
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.
> 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.
Right. Julian, what do you think about all this?
Is "making it easier to dump+load a single revision" an option to make
it possible to "fix history" (of a single revision)? Or is it a dead
end?
As I said earlier in this thread, I'm staying away from direct
manipulation of the FS (leaving that for FS-NG), but thinking about
making it as easy and fast as possible to fix things through dumpfile
manipulation (and absorbing a fixed dumpfile in an existing
repository).
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 :-).
--
Johan
Received on 2011-11-28 21:38:38 CET