Blair Zajac wrote:
> On 03/22/2010 09:46 AM, C. Michael Pilato wrote:
>> C. Michael Pilato wrote:
>>> David Glasser wrote:
>>>>> Is the attached patch what you had in mind? (Plus similar logic
>>>>> for FSFS,
>>>>> of course.)
>>>> Ah, yes, that's what I meant; that patch looks great, assuming it
>>>> works :)
>>>
>>> I'll try to polish this up, add the FSFS flavor, and add a regression
>>> test
>>> when I get some time. Thanks for the report and suggested fix.
>>
>> Committed in r926151 and r926167. I don't feel particularly compelled to
>> backport the changes as the higher-level FS stuffs *should* prevent this
>> scenario from ever occurring anyway. Do you have an opinion one way
>> or the
>> other, David?
>
> My name isn't David, but I now have 50+ repositories with 8.7 million
> revisions between them exposed via a Thrift-like API of svn_fs that
> anybody can modify the filesystem in any order, so it if a user could
> make a particular set of modifications that would trigger this, I would
> feel more comfortable with it being backported if you think there's any
> change this check would help.
>
> If we get a corrupted repository, things would be really bad, as the
> repositories are being used for an asset management system and getting
> 1+ commits/sec, it's not like there's developers who could just wait for
> the software svn repository to be repaired.
Okay. Proposed for backport. (I'm still pretty sure that you can't see
this problem if you use the FS API instead of manipulating the filesystem at
lower levels, but...)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-22 21:32:39 CET