Malcolm Rowe wrote:
> On Thu, Aug 31, 2006 at 11:32:21AM +0530, Kamesh Jayachandran wrote:
>
>> Daniel Berlin wrote:
>>
>>> It's still not going to work.
>>> Again, you can do the following, and it is supposed to work:
>>>
>>> Start an svn transaction in one process
>>> Close the transaction
>>>
>>> Start a new svn process
>>> Reopen the old transaction
>>> Commit it
>>>
>>> If you store it in memory only, this will not work.
>>>
>> Can you give a usecase where this is needed?
>>
>
> Dan just did. Our API explicitly allows the user to do the above,
> and we need to support it, unfortunately. ('Unfortunately', because
> in my opinion this isn't something that's particularly sensible to do,
> and it complicates the filesystem code).
>
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.
As This patch caches it at fs level, this info is not available to other
processes like svnadmin which is fine I believe.
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 remember 'svnadmin lstxns/rmtxns' needs this disk based storage.
>>
>
> No, you've got it the wrong way round :-). We need lstxns/rmtxns
> _because_ we support persistent uncommitted transactions.
>
Not sure what I got wrong?
Yes we need 'svnadmin (ls|rm)txns', not to dump what is there in
mergeinfo hash cache that we maintain for our internal purposes.
I don't say everything to be in memory, what I say the things like
'mergeinfo hash' here are the valid candidates for in memory.
With regards
Kamesh Jayachandran
>
> I can't see any reason offhand that you couldn't choose to persist
> the hash to disk only at transaction close time, though. Mind you,
> that does get into the discussion about the concurrent access that's
> allowed for transactions, though, which we've never really documented.
> (For example, is it valid to open a transaction that's currently opened
> by another thread/process? It's be good if we could assert that the
> answer was 'no', but I'm not sure whether we can do that).
>
> Regards,
> Malcolm
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 31 14:13:19 2006