On Jun 2, 2010, at 10:20, Thomas 'PointedEars' Lahn wrote:
> I would like to insert an older version of a file that is already in a
> repository as a specific revision of that repository.
>
> I have searched in the SVN book, searched with Google with keywords like
> "subversion file history", asked in a local newsgroup, and scanned through
> the messages here since mid of March to no avail.
>
> I think my problem is a rather complex one to describe, so I am trying to be
> concise. If you need more details to give me a hint, just ask and I'll
> provide them.
>
> One should probably usually not do what I ask about, but I needed to do it,
> might need to do it again, and this is why:
>
> I have a rather old project where I did not use Subversion from the start.
> Instead, I made backup copies in backup directories, one for each file,
> before I did major changes in the original file. Once I became aware of the
> benefits of SVN, I wanted to migrate everything into a repository, to have
> the full project history in there. So I wrote a shell script that copied
> the backup copies to my new working copy and committed the files in the
> correct order, setting svn:date accordingly.
>
> 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. 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. So to answer your questions, yes, this operation will be tedious and manual, and yes, the repository UUID must change (because the repository history is different) therefore you must discard working copies and get new ones. Therefore this is not an operation you will want to attempt after a repository is already checked out by a lot of people.
Received on 2010-06-04 02:10:10 CEST