[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: problem revealed by issue #2398 (server-side assertion)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-02-24 19:09:16 CET

Greg Hudson wrote:
> On Tue, 2006-02-14 at 10:02 -0800, Garrett Rooney wrote:
>
>>You're missing the fact that this should not be able to be triggered
>>by user data over the network. The fact that it can is a bug.
>
>
> Because of the new way the test is done, the condition could be
> triggered by data changing on the disk (the uuid file in the
> repository), and thus cannot be checked with an assert.
>
> I object to the entire sense of the commit, personally. I think
> svn_fs_merge should be demanding that the two root objects come from the
> same in-memory FS object (something you can check with an assert), and
> it's only a coincidence that neither back end puts much information in
> the in-memory FS object and thus doesn't really care. If mod_dav_svn is
> not obeying this constraint, then the bug is in mod_dav_svn.

+1.

Besides, if I'm not mistaken, part of the Berkeley DB 4.4 support work
involves ensuring that a given process only ever opens a single handle
to the repository. If that's the case, then a given httpd process
should never have multiple FS objects in memory. Is my memory and
evalutation correct?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Fri Feb 24 19:12:38 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.