On Mon, Aug 13, 2012 at 7:10 PM, Trent Fisher <trent.fisher_at_oracle.com> wrote:
>
>
> On 08/01/2012 10:49 AM, Johan Corveleyn wrote:
>>
>> On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer <saua_at_gmx.net> wrote:
>>>
>>> Hello,
>>>
>>> I'm currently reworking backups of multiple SVN repositories. In the
>>> process I found out that one of those repositories has three broken
>>> revisions. The problem is that the revision files in the revs
>>> directory for those 3 revisions are of size 0 (those contain the
>>> actual data of the revision, as far as I understand). This means that
>>> I can't use svn dump (as it stops at that broken revision) and I can't
>>> use svnsync.
>>>
>>> For the backup itself I can still use svn hotcopy (the previous way of
>>> doing a backup), so this will be my workaround.
>>>
>>> I was able to find out the affected paths in the repository and
>>> luckily the latest revision of those paths can be checked out without
>>> a problem (so we "only" lost history, not current data).
>>>
>>> But a broken repository is not desirable and I should attempt to fix
>>> it as much as possible. Losing the information of those three
>>> revisions (and a few related ones, probably) would not be a major
>>> problem, but the repository as a whole should be in a consistent state
>>> (to allow svnadmin dump to work, for example).
>>>
>>> Is there a way to remove the broken revisions and still keep the rest
>>> of the repository intact? Ideally without requiring everyone to make
>>> new clean checkouts because the repository became incompatible.
>>>
>>> regards
>>> Joachim Sauer
>>>
>>> P.S.: unfortunately there are no working backups of the broken
>>> revisions, as the corruption seems to be pretty old (older than our
>>> last full backup).
>>
>> Since you know the affected paths, I think one possible way is to do
>> an svnsync, while excluding the "corrupted paths" by way of path-based
>> authz (i.e. make the affected paths unreadable by the svnsync user,
>> using an authz file on the source repository). After that, re-import
>> the "corrupted files" from one of your working copies.
>>
>> I think everyone will have to re-checkout though, because you'll have
>> a new repository with slightly altered history. So it wouldn't be safe
>> to give this new repository the same repos-uuid, and act like it's the
>> same.
>>
>> If you search the mailinglist archives, you might find some more posts
>> about this svnsync recovery trick (excluding broken files).
>>
> I had a similar situation, though I only had one damaged revision. I did a
> dump in three segments, up to the bad rev, the bad rev and the remaining
> revs, something like this (assuming rev 44445 is the bad one):
>
> svnadmin dump -r0:44444 /some/repos > p1
> svnadmin dump --incremental -r44445 /some/repos > p2
> svnadmin dump --incremental -r44446:HEAD /some/repos > p3
> Then I manually doctored p2 to indicate that the rev is broken (but leave
> the original comment intact), then load all three into a fresh repository
> (cat p1 p2 p3 | svnadmin load /some/new/repos)
>
> The advantage of this is that the uuid and rev numbers remain the same, so
> existing workspaces will work. And this would preserve all other history of
> the given file.
>
> I just did this on a production repository two weeks ago, and no complaints
> so far.
>
> trent...
>
>>> I would do slightly differently ..
>>> let us say that 5 10 and 15 are 3 revs of the file to keep it simple
>>> as suggested before I would do the three part dump
>>> but I will load to 9 then look at the diff beween 9 and 15 subtract the diff for 15
>>> and checkin as rev 10 to the repository with the expected log and not failing to mention
>>> that this was engineered checkin [ it will be difficult if the files # are more for a checkin ..in my case was max
>>> 2 some times 1 file .. since we migrated from CVS
>>>... then continue on to load 11 to 15 ..
>>> just my 2c ...
sorry if I accidentally broke the posting sequence...
Received on 2012-08-14 07:13:31 CEST