blarg. svn_wc_prop_get

[Greg Stein <gs...@lyra.org>]

The values returned by svn_wc_prop_get are somewhat bogified. Specifically,
they don't have a pool value in the svn_string_t.

I discovered this during the commit process. I called the get_func (which
goes thru a couple steps to get to svn_wc_prop_get), got a value bak, then
tried to append to it. BAM!

This brings up an issue: svn_wc_prop_get returns a value. It takes a pool. I
would presume that the value is allocated in the specified pool, and is then
available completely for my use (i.e. not shared with somebody else). That
being the case, I would further expect it to be a "real" value that I can
then manipulate.

An alternative point of view is "the return value is still private/held by
the function; make a copy if you want to muck with it."

I believe the latter POV is bogus, tho, as the function retains no state, so
why should it do so?

This would seem to be just a run of the mill buglet, but I think there are
also some underlying issues that could do with some review/rethink. (such as
the hash reading and the svn_pack_bytestring co-conspirator)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: blarg. svn_wc_prop_get

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Greg Stein <gs...@lyra.org> writes:
 
> This brings up an issue: svn_wc_prop_get returns a value. It takes a pool. I
> would presume that the value is allocated in the specified pool, and is then
> available completely for my use (i.e. not shared with somebody else). That
> being the case, I would further expect it to be a "real" value that I can
> then manipulate.
> 
> An alternative point of view is "the return value is still private/held by
> the function; make a copy if you want to muck with it."

Nah.  Why bother to require a pool?  Requiring a pool implies that the
info you get back is "yours".  

This is just really, really old code.  We'll fix it this morning for
ya.

 
> This would seem to be just a run of the mill buglet, but I think there are
> also some underlying issues that could do with some review/rethink. (such as
> the hash reading and the svn_pack_bytestring co-conspirator)

Well, we'll *also* have to use the pool you give us to read the props
from disk into a hash.  But we could subpool your pool, build the
hash, dup the one wanted value into the original pool, then free the
subpool.  Sound good?

In the long run, we agree that it's Losing that any time a property is
get or set, we currently have to load the *whole* proplist into
memory.  Maybe someday we'll use db instead, or somehow stream-ify
props.