On Thu, Aug 31, 2006 at 05:41:03PM +0530, Kamesh Jayachandran wrote:
> We do this 'mergeinfo' hash cache (forget about in-memory or disk) to
> avoid iterating the 'proplist' upon commit to get the same info and not
> to rely on 'proplist'(As eventually we won't store mergeinfo as
> properties). This 'mergeinfo' hash cache is for our convenience not for
> the end user to query, So I feel it does not need to be exposed to disk.
>
Ah, so the mergeinfo information is simply a derived version of the
information already available in the svn:mergeinfo property? I didn't
realise that.
As a general question, how do you manage cache coherency between the
information in the property and the information in the hash? Or doesn't
it matter? (perhaps because the property won't change during the period
that the hash is in use?).
> As This patch caches it at fs level, this info is not available to other
> processes like svnadmin which is fine I believe.
>
From the sound of things, this cache is an implementation detail, so
nobody outside of libsvn_fs_fs should need to know about it, or be able
to detect that it's in use.
> Regarding complication, I am not sure how?
> Except for the fact it happened to be after thought/round about
> solution. The more correct solution would be to make
> 'fs_change_node_prop' receive the already open txn.(Which I believe
> backward incompatible solution). Then we can use that persistent in
> memory txn for caching things like this.
I don't understand this, I'm afraid. fs_change_node_prop() takes a
transaction root, so you already know which transaction it refers to.
If you mean that we don't have an fs-internal transaction object to hang
fs-specific data onto, then, as I understand it, that's a deliberate
decision [to refer to transactions solely by name inside the FSFS code].
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 1 17:56:49 2006