On 2/24/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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?
I do agree that this is a bug in mod_dav_svn, but as far as BDB 4.4, I
believe the limitation is being handled by a global cache of BDB
environment handles, so having two subversion level filesystem objects
isn't a problem, they'll just poin to the same BDB environment object.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 24 19:20:39 2006