Re: svn commit: rev 5677 - in trunk/subversion: include libsvn_wc

On Mon, Apr 28, 2003 at 05:55:04PM -0500, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > In most of these functions, 'associated' can be NULL, right? For example,
> > the first time you grab an access baton.
>
> In the _open functions, associated can be NULL, because that just
> means you don't want to associate the new baton with an existing set.
>
> In the _try functions, it can be NULL, but if it's not, it's still
> okay if the set does not have the requested baton -- just _open it and
> add it to the set.

Right. Got those parts.

> > So... I'm a bit unclear on whether a problem truly exists, but it doesn't
> > feel quite right. Certainly, the expectation of being able to pass NULL to
> > some of these functions for the "associated" set is not very clear. Which
> > allow it, and which don't. (it looks like the retrieve functions will crash
> > if you pass NULL)
>
> They should crash, yes; and they are the only ones that should.
>
> I'll have to look at this in more detail, to tell whether it's just a
> doc problem or an actual code problem. (Did the clarification above
> change anything for you? That would indicate a doc problem...)

I think the new _try() variants can crash because they assume the associated
set exists, so that it can retrieve a pool for the new baton.

It isn't crashing in our case because the client add/delete functions will
manually open an access baton, and then call the svn_wc_* function with that
baton as the associated set.

IOW, it appears that all of our current uses of svn_wc_* pass in an
associated set, which is why we aren't seeing any crashes right now.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org