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

Re: Insert revision into file history

From: Thomas 'PointedEars' Lahn <PointedEars_at_web.de>
Date: Mon, 21 Jun 2010 13:42:11 +0200

Ryan Schmidt wrote:

> Thomas 'PointedEars' Lahn wrote:
>> [...]
>> The problem was that this script missed to commit the first version of a
>> file, and I noticed that only after I had already worked with the
>> repository for quite a while. This is how I solved it (apparently,
>> somewhat):
>> On the server:
>> 1. Backup the entire repository $PROJECT to $BACKUP.
>> 2. svnadmin dump $BACKUP -r 0:6 > $PROJECT-0-6.svndump
>> (6 was the revision with an svn:date just before the date of the old
>> version to be inserted)
>> 3. Delete $PROJECT.
>> 4. svnadmin create $PROJECT, restore config and hooks (except
>> post-commit). 5. svnadmin load $PROJECT < $PROJECT-0-6.svndump
>> On the client:
>> 6. svn checkout svn://$HOST/$PATH/$PROJECT/trunk .
>> 7. Copy older version from backup directory to working copy,
>> svn add ..., svn commit.
>> Back on the server:
>> 8. svnadmin dump $BACKUP -r 7:15 --incremental > $PROJECT-7-15.svndump
>> (16 was the revision where the file was previously first committed,
>> no other changes in that revision)
>> 9. svnadmin load $PROJECT < $PROJECT-7-15.svndump
>> 10. svnadmin dump $BACKUP -r 16 > $PROJECT-16.svndump
>> 11. Edit $PROJECT-16.svndump to change
>> Node-action: add
>> into
>> Node-action: change
>> (otherwise `svnadmin load' would error out "path already exists")
>> 12. svnadmin load $PROJECT < $PROJECT-16.svndump
>> 13. svnadmin dump $BACKUP -r 17:HEAD --incremental >
>> $PROJECT-17-HEAD.svndump
>> 14. svnadmin load $PROJECT < $PROJECT-17-HEAD.svndump
>> 15. Update svn:date of new revision 7, restore of post-commit hook.
>> However, the issues I have with my solution are:
>> 1. It is rather tedious to implement and eats up time better spent for
>> development.
>> 2. I don't see how it could be automated.
>> 3. I have noticed that the working copies can no longer be
>> updated/committed as the checksum does not match. This is a big
>> problem if I want to go fully open source with that project, as
>> potential contributors would need to rebuild their working copies
>> every time I find another such glitch.
>> SVN version on the client was/is 1.6.11 (Debian package); the server runs
>> `svnserve -d' from SVN 1.5.1 (Debian package).
>> Which better/easier/faster way to do this am I missing? Thank you very
>> much in advance for any suggestions.
> Yes, this operation is tricky to perform, because Subversion is not
> designed to let you perform it. If anybody could just go insert anything
> into a repository's history, we wouldn't be able to trust that history
> very well.

Thank you very much for your answer. I see your point, but since the UUID
changes, that would already indicate that we are dealing with a different
repository which may therefore have a different history. So I still think
it would be worthwhile to have that possibility of "remembering" older
revisions of a file (since "forgetting" them is possible by default).

I will further try to automate it if and when I find the time (although I
probably cannot do anything about the changing UUID, maybe I can do
everything on one host) and post my solution here, then.

> So yes, getting this to work is an involved process. I'm not
> sure if there's an easier way than the one you found. I might have looked
> into using svndumptool and would have been wary of modifying dumpfiles by
> hand. But I'm not sure it could have been done with svndumptool anyway.

Thanks, SvnDumpTool might be what I was looking for.

Received on 2010-06-21 13:43:06 CEST

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

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