On IRC, there was a discussion about the wc_db API. In particular
whether to have lots of query functions, or to have the caller sort it
out. As Bert noted, my original intent was to provide the caller with
enough information and let it sort everything out. That keeps the API
cleaner, and it also moves the filtering out of wc_db. Generally, the
particular pattern/rules of filtering changes with almost every
caller. It is pretty hard for wc_db to provide generic mechanisms for
filtering.
*If* there are typical patterns, then those functions can be put into
util.c or something, building upon the basic wc_db API.
I also don't like to see structures like svn_wc__db_info_t. We had a
big problem with the entry_t, and things like info_t will continue to
propagate that broken model. By definition, to use that structure a
query must be done against both NODES and ACTUAL_NODE. That is fine
for read_children_info, but if that structure starts migrating to
other places, then we're going to head back into the area where we
grab unneeded information. *Thankfully*, that structure is internal to
WC. Part of entry_t's problem was its external nature, making it hard
for us to change that in any way.
Structures like svn_wc__db_walker_info_t are much better: focused and
minimal, concentrating on providing the basic information that
(presumably) most callers would want.
Last point, and meta: discussions should take place on the dev@ list
as much as is reasonably possible. Or at least after an IRC discussion
moves towards conclusion, to bring that to the list. That ensures that
the entire community can be included. Keeping primary
discussions/resolutions to IRC will exclude people who may want to
participate (because they don't hang out on IRC or because of time
zones).
Cheers,
-g
Received on 2011-03-11 20:13:38 CET