Malcolm Rowe wrote:
> On Thu, Sep 14, 2006 at 12:15:49AM +0530, Kamesh Jayachandran wrote:
>
>>> Our API guarantees that the following scenario must work.
>>>
>>> Process 1: Create new transaction (Tx1)
>>> Set properties (including mergeinfo properties)
>>>
>>> Process 2: Open transaction Tx1
>>> Query (mergeinfo) properties set by process 1
>>>
>>> Process 1: (Continue to work with still-open transaction Tx1)
>>>
>>> How do you propose to support that in your design?
>>>
>>>
>> I would like to make one thing clear here.
>> Today we have mergeinfo in 2 places.
>> 1. in proplist (Which should be sufficient for the case you mentioned above)
>> 2. in mergeinfo hash used for convenience not meant to be used by
>> anyother process other than the one that creates it. This mergeinfo hash
>> is short lived entity gets deleted upon successful commit of the txn.
>> Hope I made it clear.
>>
>>
>
> Yes, and if you aren't ensuring coherency between the hash and the
> proplist, how do ensure that the processes above see the same view of the
> transaction? Or, if you're doing write-through on the hash->proplist,
> how do you invalidate process 1's existing cache when process 2 makes
> a change to the hash?
>
Yes I got your problem.
Now I have one fundamental question.
I could not find the command line(svnadmin/svnlook) to modify the
'versioned proplist'(In this case 'svn:mergeinfo'), I believe having
such a feature is not logical as it would end up user's working copy
inconsistent with what gets committed.
So I believe the versioned property like 'svn:mergeinfo' is not supposed
to be modified any other process than the one which creates them and
hence no cache coherency issue.
> I should point out that this isn't just theoretical - ra_dav issues
> many (potentially overlapping) requests in the lifetime of a single
> Subversion transaction, and these may end up being serviced by different
> httpd processes.
>
Are they working over the 'persistent props'?
> Any design that requires me to know whether other processes might be
> modifying the transaction I'm working on before I can decide whether
> to do a query using a fast-but-possibly-out-of-date in-memory hash or
> a slower-but-correct on-disk proplist is terminally broken, sorry.
>
>
Given my above explanations, I fail to see the problem over here.
To summarize (correct me if I am wrong)
We have 'persistent versioned (not the txn props like 'author/log/date')
proplist having svn:mergeinfo'(Which I beileve readonly to other
processes than the one created them), In the place where we populate
this 'svn:mergeinfo', we populate this hash, just to collect all such
'svn:mergeinfo' to one hash and blow the sqlite at the end by reading
from this hash.
As this data is readonly to others we can have in-memory hash here. Or
we can remove this altogether, as I could not see any great value in
doing this.
Let me know in case I am not clear.
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 Thu Sep 14 08:45:53 2006