How do subversion clients deal with a historic change in a repository?

Question

I had to make a change to a subversion repository database. I created a dump, filtered out a revision and created a new database.

This new repository of course shares a lot of content with the working copies clients of the old repo already checked out, however, it is missing a revision inbetween.

The revision that was removed did not add any data, it only changed some files.

Is it possible to simply replace the old server database with the new one without causing havoc on existing clients working copies? Or do I have to have all clients check out a fresh copy of the new repo instead?

More generally, how do subversion clients deal with a change in structure on the server side? I'm primarily interested in TortoiseSVN.

Answer 1

As long as the revision numbers weren't changed in the dump, and the UUID was kept, it shouldn't make much difference. Subversion tracks the revision number of the working copy files and the UUID and URL of the repository. Even if the history was changed, it shouldn't affect the working copies.

HOWEVER, there's always a difference between theory and fact. Before doing a dump and load, I'll warn the developers in advance. I have them check in their code. Then, I do a dump and load, then tell the developers to do a clean checkout.

Just to be safe, do a clean checkout. You can do a svn status on the old working copies to find files that were changed but not committed and copy them off to your new clean checkout. The svn status doesn't ping the repository, so that's a safe operation.

Answer 2

We had an issue with a corrupt checkin once, which required me to remove it from the repo. I ran a few test checkins after the work was complete, so the latest revision number was at least the same (if not greater) than what the other developers had on their box. We didn't have any issues doing this.

Answer 3

From my experience the Tortoise SVN client 1.7 grows his .svn directory steadily and reduces it only when you run a "cleanup" on the top of the working copy.

Also, if a TSVN already saw the log message (and other details) of the filtered revision, it will continue to show it to the user, unless he clears this specific cache (which is possible with the GUI).

I would not try to keep the old working copies if you filtered a whole revision including its distinct revision number (so that the next revision got the filtered revision's number now).

I do not know more about the interior of the clients to directly answer your question. but I was in a similar situation and thus I suggest to first test the server.

• run "svnadmin verify" on the new (filtered) repository

Even more your svnadmin load (or svnrdump load) should have already stumbled upon missing history ("delta"). But I suggest to gather more proof that the server really does deliver:

From the new repository, while watching the server and your favorite client closely for any warnings...

1. checkout at least the files which are affected by your filtering and - for good measure - the directories above these files. (The directories do not need to contain the other files and subdirs, I guess.)
2. update this checkout to one revision before the filtered one, then one revision after the filtered one
3. try to checkout/update to the filtered revision if it still has a revision number
4. test (2.) does not prove too much, if the files are not modified in those revisions, so update to revisions as needed to switch all the files back and forth, between their states before and after another modification before and after the filtered one, if available. To see if the "gap" in history causes trouble.