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
