Malcolm Rowe wrote:
> 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.
>
Yes.
> 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?).
>
>
They will be coherent as we update the cache hash upon change prop.
>> 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.
>
No it recieves svn_fs_root_t*, not 'transaction root'.
From svn_fs_root_t getting the same in memory versions of 'txn' is not
possible.
All svn_fs_root_t has is 'char *txn' not 'svn_fs_txn_t*'.
Now I think of one solution not sure how correct it is!!!
Why not make 'svn:mergeinfo' as txn prop as against the 'versioned prop'
and make use of the 'svn_fs_fs__txn_prop' of txn_vtable.
This also solves the duplicate mergeinfo one in sqlite and another in
properties.
> 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].
>
I did not understand this.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 1 19:38:29 2006