Daniel Rall wrote:
> On Wed, 11 Oct 2006, Kamesh Jayachandran wrote:
>
>> Daniel Rall wrote:
>>> Thanks for the patch, Kamesh. I've made some changes to it and the
>>> change log message (attached), but I have some additional questions:
>>>
>>> Is it 1) appropriate and 2) necessary to push knowledge of skels
>>> corresponding to specific properties (e.g. SVN_FS_PROP_TXN_MERGEINFO)
>>> down into fs_skels.c (rather than knowledge which ends at the concept
>>> of "proplists", as on trunk)? To me, that file seems like a more
>>> generic utility which shouldn't contain such specific knowledge.
>> I think somehow we can't avoid that. Someway or the other parsing
>> code(which should sit inside the util/fs_skel.c) should know about
>> 'SVN_FS_PROP_TXN_MERGEINFO'. Or we should treat the value of
>> 'svn:txn-mergeinfo' as 'atom' and parse it outside?
>
> I chatted with Mike Pilato about this a bit. If we're initially using
> sqlite for the merge info index, we should not be attempting to
> store/retrieve merge info properties as structured data! They should
> be stored simply as atoms.
>
> If we wanted to jump directly to storing merge info in BerkeleyDB,
> we'd need to replace all usage of the sqlite-based svn_fs_merge_info.h
> APIs in the BDB backend. While we continue prototyping an end-to-end
> Merge Tracking solution, I would prefer to avoid this redundancy for
> the sake of simplicity.
Yeah, I think the key consideration here is that many times, the code
that parses property lists doesn't care about the individual property
values or their interpretation as structured information.
svn_fs_txn_proplist() doesn't care that there is such a thing as
merge-tracking information. By breaking down that one property into
sub-skels, you add computational overhead that is not generally needed.
Keep the merge-tracking property as a single blob of data to appease
the majority of the consumers of that information; parse it into a
structure for particular interfaces that require it (but at a layer
above the skels stuff).
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Oct 11 20:55:04 2006