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
