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.
PointedEars
Received on 2010-06-21 13:43:06 CEST