[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]sqlite mergeinfo indexing for bdb repositories

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-10-11 20:54:47 CEST

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

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.