Daniel Rall wrote:
> On Thu, 14 Sep 2006, Kamesh Jayachandran wrote:
> ...
>
>>>> Do we have any plans to have different 'mergeinfo' stores for each repo
>>>> backend type? Then I agree this need to be part of individual backend.
>>>> If we have different type of backend 'mergeinfo' store for each repo
>>>> type then most of this exercise is not needed and sqlite related stuff
>>>> could be left in libsvn_fs_fs itself.
>>>>
>>> I see no reason to unnecessarily dictate the type of merge info index
>>> used by a backend. Encapsulating the storage type inside the FS
>>> backend module adds very little overhead.
>>>
>> Then I see no meaning in the existence of libsvn_fs_util(Which I believe
>> is meant to hold the reusable sqlite code.)
>> Correct me if I am missing something.
>>
>
> libsvn_fs_util is important:
>
> 1) As we really need to focus on getting an end-to-end Merge Tracking
> prototype completed, the sqlite merge info index you're moving to
> libsvn_fs_util may be used by both the FSFS and BDB backends for a
> first cut. The API, on the other hand, shouldn't be dictating this as
> a requirement (BDB might later want to use its own schema, the Google
> backend might have other ideas, etc.).
>
> 2) C-Mike has mentioned that there's non-Merge Tracking related FS
> code which he'd like to put into libsvn_fs_util module so that it can
> be shared between the FSFS and BDB backends.
>
Fine will post a patch adhering to your comments soon.
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 15 14:42:37 2006