On 7/10/07, Melikian, Chris <Chris.Melikian@uk.fid-intl.com> wrote:
> These are the exact same symptoms that we see here. We have also been
> able to commit on top of a broken revision. SVN seems to ignore broken
> revisions when it's computing deltas and perhaps commit the entire file?
No, in earlier conversations I pointed to a document describing how
skip-deltas work. The behaviour you're seeing is totally expected,
until the skip-deltas start to depend on your broken revision. It's
not ignoring the revision, but only using the tree-information stored
in the broken rev. The content is indeed ignored or rather not
required. That has however nothing to do with the revision being
broken or not.
HTH,
Erik.
>
>
> Chris Melikian
>
>
> Important: Fidelity Investments International (Reg. No.1448245),
> Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity
> Pensions Management (Reg. No. 2015142) and Financial Administration
> Services Limited (Reg. No. 1629709, a Fidelity Group company) are all
> registered in England and Wales, are authorised and regulated in the UK
> by the Financial Services Authority and have their registered offices at
> Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11
> 9DZ. Tel 01732 361144. Fidelity only gives information on products and
> does not give investment advice to private clients based on individual
> circumstances. Any comments or statements made are not necessarily those
> of Fidelity. The information transmitted is intended only for the person
> or entity to which it is addressed and may contain confidential and/or
> privileged material. If you received this in error, please contact the
> sender and delete the material from any computer. All e-mails sent from
> or to Fidelity may be subject to our monitoring procedures. Direct link
> to Fidelity's website -
> http://www.fidelity-international.com/world/index.html
>
>
>
> > -----Original Message-----
> > From: Douglas Pearson [mailto:biz@sunnyhome.org]
> > Sent: 09 July 2007 23:00
> > To: users@subversion.tigris.org
> > Subject: RE: Serious error in repository--help needed
> >
> > Thanks for the suggestion and we'll follow up with the
> > fsfsverify guy to see
> > if he can help.
> >
> > Interestingly today there has been a change in the problem.
> > A new commit of
> > the file that was having the checksum error seemed to:
> > A) work (surprising us as we assumed it would try to compute
> > a delta and
> > fail)
> > B) masked the earlier problem
> >
> > That's to say, an update or checkout of the repository as a
> > whole is back to
> > working now without any errors. Running "svnadmin
> > dump/verify" still fails
> > with the same error, so the earlier revision is still
> > corrupted, it's just
> > somehow ignored now. Presumably SVN has some way to determine when it
> > doesn't need to look at an earlier revision to compute the
> > latest copy of
> > the file and that's now cut in.
> >
> > So it looks like the patch tool we needed was to run "svn
> > commit" again in
> > some particular way :)
> >
> > Of course, this still leaves us with a partially corrupted
> > repository with
> > no way to run a dump/restore but at least it's semi-functional again.
> >
> > If any of the SVN devs would like a copy of the corrupt
> > revision or any
> > other info about the repro case here I'm happy to pass it along.
> >
> > Doug
> >
> > -----Original Message-----
> > From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> > Sent: Monday, July 09, 2007 12:50 AM
> > To: Douglas Pearson
> > Cc: users@subversion.tigris.org
> > Subject: Re: Serious error in repository--help needed
> >
> >
> > On Jul 8, 2007, at 22:56, Douglas Pearson wrote:
> >
> > > That's very disappointing to learn that we're really sunk here.
> > > Anyone else
> > > have any other ideas beyond a complete rollback of the
> > repository and
> > > presumably days of struggling to find all changes and get them back
> > > into the repository?
> > >
> > > As to the cause, the description on the "fsfsverify" page
> > > http://www.szakmeister.net/blog/?page_id=16 (and the
> > existence of that
> > > patch tool, which BTW is a year and a half old) seem to
> > describe our
> > > situation pretty accurately. Committing a large set of
> > changes (this
> > > revision is about 40MB) through apache2 can lead to an invalid
> > > revision on disk. As I say, we've seen that pattern several times,
> > > but only when working with large commits and never consistently.
> > >
> > > However, there's something different about this corruption than the
> > > earlier ones as the fsfsverify script fails to correct this problem.
> > >
> > > As to whether there should be recovery tools, well frankly
> > that seems
> > > like a no-brainer to me. If SVN can cause corruption under normal
> > > usage (not some weird power outage or disk failure case
> > here--just a
> > > normal commit) then it should be able to recover from those
> > > corruptions. It may be the error is inside Apache, but
> > even if that's
> > > true SVN needs to be able to get back to a working state.
> >
> > As I understand it, fsfsverify exists because the Subversion
> > developers have
> > not yet been able to properly track down what causes these
> > corruptions to
> > occur. They have only been able to write this script which
> > corrects the
> > corruptions after the fact. They have presumably not run into
> > the problem
> > themselves, else the problem would be easier for them to solve. The
> > corruption you have now experienced, which could not be corrected by
> > fsfsverify, could be significant. You should contact the developer of
> > fsfsverify and provide him with as much information as you
> > can. If this
> > corruption is indeed similar to that already handled by
> > fsfsverify, perhaps
> > fsfsverify can be enhanced to also handle your type of corruption.
> > And perhaps this will even lead them one step closer to
> > finding the cause of
> > the problem in the first place, and fixing it once and for all in
> > Subversion.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 14 13:54:49 2007