[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Altering copyfrom information in repository

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Mon, 28 Nov 2011 23:31:23 +0200

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.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

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
Received on 2011-11-28 22:34:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.