Re: svn commit: r12063 - in trunk/subversion: libsvn_ra_svn svnserve

On Mon, 2004-11-29 at 11:21, kfogel@collab.net wrote:
> > + path = svn_path_canonicalize(path, entry->pool);

> Just curious: why is it better to use entry->pool here instead of
> pool? I've no reason to think it's wrong, would just like to
> understand better.

It's not; "pool" would have been better.

> The lack of internal interface documentation in libsvn_ra_svn makes it
> hard to know the pool lifetimes, oh well.

pool lives for the lifetime of the function call and any object it
returns to the caller (which in this case is nothing). entry->pool
lives as long as the entry.

This is true of essentially every function we have which takes a pool,
and of essentially every object we have which contains a pool. Why
document it for every function? Should we also document what pools are
and how they work, for every function?

> In the first case, in editor.c, the next call, to
> ds->editor->delete_entry(), used 'entry->pool' too. But here, the
> next call, also ds->editor->delete_entry(), uses 'pool' instead.

Both should be using pool. The only reason to use entry->pool is if
you're creating an object which is going to live in the entry.

The discrepancy is because editorp.c (the code which normally gets used)
was fixed, while editor.c (the pre-0.34 compatibility code) was not.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 29 17:57:23 2004