Daniel Berlin wrote:
>>
>> 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.
>
> No, there is no command line tool to modify it, but that does not mean
> our API does not support it.
>
>>
>> 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.
>>
> This is an incorrect statement of what the API allows.
> Whether we like this or not, it is the way it is. It does allow the
> property to be modified by other processes.
>
> It is not readonly to them.
Ok, will play with the binding once I have them.
>
>> >
>> Given my above explanations, I fail to see the problem over here.
>>
> The problem is that our API explicitly allows it.
> Nobody is saying you are incorrect that this *isn't useful and logical*.
> In fact, AFAIK, both Malcolm and I agree that it is not a useful feature.
> However, regardless it *IS* a requirement that we support it until SVN
> 2.0, regardless of its merit. That is the guarantee we have made
> about our APIs.
I fail to see how it will break the BC issue.
My in-memory hash is just going to add one more member to fs_fs_data_t.
As fs_fs_data_t is a private data structure changing it is not a BC issue.
Correct me if I am wrong.
Only think I am not sure about is it the right place to cache the info
of this kind. Even the multi threaded scenarios where multiple
threads(txns) sharing the same fs_fs_data_t.
With regards
Kamesh Jayachandran
>
> Having to serialize merge tracking info to disk in transactions is the
> price we pay for this guarantee.
>
> This is why both Malcolm and I believe this guarantee should be
> removed in SVN 2.0. But we cannot remove it in SVN 1.5.
> --Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 14 09:46:46 2006