[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH][merge-tracking] libsvn_fs_util

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-09-15 14:42:50 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.