[Begging your pardon for not being able to speak with confident accuracy about the inner workings of WC-NG.]
Today, while trying to get an overview of the various ways in which
svn_wc__node_walk_children() was used, I found some patterns that seem, to
me at least, to cry out for better database schema support:
- set PROPNAME=PROPVALUE for all nodes at or under TARGET up to some
depth ('svn propset --depth DEPTH PROPNAME PROPVAL TARGET').
- remove PROPNAME from all nodes at or under TARGET up to some depth
(svn propdel --depth DEPTH PROPNAME TARGET).
- fetch the value of PROPNAME for all nodes at or under TARGET up to
some depth ('svn propget --depth DEPTH PROPNAME TARGET'; also
much of our svn:mergeinfo handling).
- invalidate dav cache property PROPNAME for all nodes at or under
TARGET up to some depth.
None of these operation is particularly straightforward without a row-by-row
walk today in the way you might expect from a relational database system.
Properties are all wrapped up in skels. The "deletion" of a property is
really an update to the property set skel to not contain that property any
more. That kind of stuff.
Philip points out that we might be able to add some custom sqlite functions
to manage at least the "read" subset of these operations. But I find myself
wondering if we wouldn't be better served by having a properties table with
rows for, I dunno: wc_id, local_relpath, property_name, property_value.
It's pretty naive, yes. Oh! And either put the dav cache properties into
this table alongside the more user-facing properties, or make a separate
dav_cache table with the same schema, or just punt on those (recognizing
that we're trying to move away from the need for those altogether).
Was this considered when we moved the properties into the database? If so,
why didn't we take this approach? Should we consider it now? Should we
punt it to 1.8?
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
