On Mon, Aug 13, 2012 at 7:10 PM, Trent Fisher <trent.fis...@oracle.com> wrote: > > > On 08/01/2012 10:49 AM, Johan Corveleyn wrote: >> >> On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer <s...@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...
