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.
- application/pgp-signature attachment: stored
Received on Thu Sep 14 18:53:33 2006