Re: verify signals problems: can a revision be ignored?

On Wednesday 15 August 2007 15:08, Jose Miguel Pasini wrote:
> % svnadmin verify /home/jpasini/svn_repos/
> ...
> * Verified revision 34.
> svnadmin: Failure opening '/jm_website/trunk/WebContent/bio.html'
> svnadmin: '/jm_website/trunk/WebContent' is not a directory in
> filesystem '/home/jpasini/svn_repos/db'
>
>
> I don't know the cause of the problem (I must have messed up while using
> RapidSVN), but now I would like to be able to at least "ignore" or
> "erase" this revision (35).

No, you did not mess up with RSVN. Rather, this means that some data was
destroyed which belongs in your repository, but Subversion itself doesn't
offer any way to destroy that data (unless you encountered a bug, that is). I
would be very interested in knowing how that data vanished, as it might
happen again (HD failure, virus, unclean unmounting etc).

Anyway, what does that mean? It means that this revision or parts thereof are
not available. You also can't simply ignore that, because a later revision
might refer to that revision's data (remember, SVN stores deltas!), so you
need to fix that.

> I can check out the older revisions, and I would like to simply commit
> the latest working copy I have, but I'm paralyzed at this stage by these
> errors.

1. Make a backup of the whole repository and your working copies now, do not
attempt any remedy on them without this.
2. If you can dump everything after that revision, you can load the content up
to r35 from a backup and then incrementally load the dump you extracted from
the current repository.
3. If you don't have a backup of r35, it gets difficult. You might be able to
dump 0..34 and then load 36..HEAD on top of it. This would mean that a) the
content of that revision is lost and b) that working copies get out of sync,
because their revision doesn't correspond to the same revision in the
repository anymore. I think you can tell svnadmin to create an empty revision
to avoid that.
4. Same as 3., but you manually recreate the changes you made in r35.
5. You can dump 0..34 and then commit your working copy's data on top of it.
Note that you need a new WC for that. Obviously this looses any history
information between 34 and HEAD, but you get the current data into the
repository.

Note that you can read about the dump/reload operations in the Subversion
book, which is why I didn't go into those here.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Ronald Boers, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org