Dirk Schenkewitz <schenkewitz@docomolab-euro.com> wrote:
> Could you shortly describe what you tried?
>
> I would do the following:
> A) copy a WC to another name, perhaps 2 times while you're at it.
> Then do an
> svn revert to switch back to what should be the latest checked in
> version if the server would be fine. Then try to checkin. If that
> does not work:
> B) checkout the latest version from the server to a NEW directory.
> Copy everything from the just 'revert'ed WC into it. Check in. This
> must work.
> C) at last copy everything from the unreverted copy ontop of it.
> Check in.
This won't work because every remote operation doing on the WC requires the
base revision of the WC itself to exist, and it requires *that* version of the
repository to actually *match* the text-base contents of the working copy,
since the server and the client talk through deltas assuming this.
Say you restored up to r100 from the backups. All the working copies after r100
are doomed. If you have three working copies pointing at r120, r140 and r160,
you should first collect them from the users, then restore them with the trick
you suggested (checkout, copy all the files over, commit) *and* adding padding
(blank) commits into the repository so that r120 in the server actually matches
the text-base version of the r120 repository, and so on for all three of them.
Now think if you 500 working copies around.
And notice that you're still doomed to fail because the checkout + copy files +
commit trick does not correctly takes care of the *properties* of the files. If
you don't restore the properties, you are in big trouble if they ever change
again, since the working copies will be desynchronized (eg. they will think
that a certain file does not have properties, while the server thinks it has),
so the first time some delta is transmitted, there will probably be some
errors.
Also, another really negative thing is that there's no way of flagging working
copies as "bad". I told my users to destroy their working copies, but what if
they forget / do mistakes, and work in a desyncrhonized working copy? They're
probably bound to go into even deeper trouble. And there's really nothing I can
do. The only thing I thought of was dumping the whole repository and reloading
it into a *new* repository, with a new UUID, so that the old working copy
wouldn't work. But I have other projects in the same repository, and I didn't
want to invalidate working copies of the other projects too. And I didn't want
to manage *another new* Subversion server just for this project.
The net result is that now I have a post-commit hook which dumps and backups a
revision as soon as it is committed. I believe that any other backup strategy
for a SVN server (say, hotcopy once a day) is basically useless.
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 10 01:59:09 2006