Michael Matz wrote:
> Hi,
>
> On Wed, 23 Feb 2005, Stephan Kulow wrote:
>
>
>>Doing some strace on the server it became obvious, that the server was
>>simply running out of memory. Having had some bad experience with cvs,
>>we set a ulimit on our server to disallow (unintended) DoS attacks. But
>>128MB are fine to do a commit, no?
>>
>>Now before the server was aborted due the ulimit, it was acting like
>>this in the strace:
>>
>>open("/home/kde/db/revs/330743", O_RDONLY|O_LARGEFILE) = 4
>>_llseek(4, 8452, [8452], SEEK_SET) = 0
>>read(4, "id: 1.0.r330743/8452\ntype: dir\np"..., 4096) = 627
>>close(4) = 0
>
>
>>[... opening _all_ revs in reverse, even those not containing files
>> touched by the commit ...]
>
>
>>Why is svnserve (version 1.1.3 btw) doing that? If this is happening
>>whenever two people commit at the same time, then I'm afraid this would
>>make KDE moving to subversion impossible ;(
>
>
> It's 100% reproducable, so any idea anyone on this list? Anything we can
> try to help solving this problem (short of using bdb, and does it really
> not have this problem of opening all revs, even if it couldn't be
> noticed by a simple strace)? This is a showstopper for using svn as
> KDEs version management system, as concurrent commits to separate subtrees
> need to be possible.
>
> AFAIU the above shouldn't happen due to skip lists (or however you call
> them ;-)) and anyway should touch only revs affected by the commit, not
> all of them, but the strace shows that this is not the case.
Skip lists mean you don't need to apply all the deltas from each
revision, you still have to open the rev file in order to find the
dirents for directories in previous revisions, it has nothing to do with
the skip deltas used for the actual file contents.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 25 23:58:49 2005