On Jun 2, 2009, at 20:24, Syd Bauman wrote:
>> The usual wisdom is that if your old server and new server use the
>> same architecture, same major OS version, same version of APR and
>> Subversion, you can just copy the repository, but for anything more
>> complicated, a dump and load is recommended. With a BDB repository,
>> copying the repository to a different architecture shouldn't work
>> at all, I believe. So the fact that yours is slightly working means
>> you have an FSFS repository. I'm not sure if the issues you're
>> seeing are due to such issues, but if possible, try to find a
>> machine with the same specs as the one that died, put the
>> repository on it, and run svnadmin dump on it. Then try to load
>> that dumpfile into a new repository created on your new server.
> Thank you for your response, sir! In the interim I have done an
> experiment that leads me to believe that regenerating the repository
> from a dump file would not help.
> I moved the repository elsewhere for safekeeping:
> # mv /usr/local/repositories ~/
> I then created a brand new repository under the auspices of a
> Subversion system on the new architecture:
> # mkdir /usr/local/repositories/
> # svnadmin create --fs-type fsfs /usr/local/repositories/TST/
> # cd /usr/local/
> # chown -R svn repositories/TST/
> and tested the new TST repository ... I got the same error. I then
> remembered to change the default passwd file and tried again, still
> got the same error. :-)
> If the general wisdom is that it's still worth trying to create a
> dump and load it, I will do that. But it's going to be a few hours
> work, so if you think the above experiment demonstrates that there's
> no point, I'd just as soon not bother.
You make a pretty convincing case that the problem is not the old
repository but something about how the new server is set up.
Unfortunately I'm not certain where the problem is.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-03 03:35:06 CEST