Greg Stein <email@example.com> 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
> 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
Received on Sat Oct 21 14:36:26 2006