[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 3215

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-09-24 17:03:47 CEST

Philip Martin <philip@codematters.co.uk> writes:
> Um, would you believe "laziness" :)
>
> I've been passing these access batons around for so long without
> getting much benefit, I was keen to see something more concrete, and
> simply changing the pools was a quick-n-dirty solution.
>
> What needs to be achieved is that the access baton pool is used for
> everything that is referenced by the hash of entries, otherwise the
> cache will become outdated. It looks like fold_scheduling doesn't
> need to be passed the access baton pool, since the pool is only used
> for errors. On the other hand fold_entry does use its pool for
> allocations, so for the cache to work these allocations must occur
> from the access baton pool.

Gotcha. It sounds like we'll need some conventions for documenting
pool behavior for functions that take access batons, or that take
objects allocated from (or together with) access batons.

To fix up svn_wc__entry_modify(), it sounds like

   * svn_wc_entries_read() must document what it allocates in the
     access baton pool vs what it allocates in its other pool,

   * fold_scheduling() must promises to only use its pool for errors.
     Currently, it doesn't document its pool argument at all :-).

   * fold_entry() will need to document that it can use pool to
     allocate data it adds to entries. It also needs to document any
     lifetime requirements of its `name' parameter. Depending on the
     above, perhaps the allocation of `name' in svn_wc__entry_modify()
     can just happen in `pool' right now...

Hmmm, this is complicated. Do you want me to file an issue, or is it
on your list anyway?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 17:28:34 2002

This is an archived mail posted to the Subversion Dev mailing list.