>From IRC this afternoon: [2:55pm] Bert: Maybe it would be easier to build an api to get you a list of targets that match a specific depth... And then pass that list of targets to libsvn_wc. (In theory it might blow out of memory; but it keeps things simple) [2:56pm] Bert: Then libsvn_wc does it or doesn't do it.. And you can just notify that list
That got me thinking. Most of the libsvn_wc APIs have been expanding to accept multiple paths, depths and changelist filters. Rather than crafting several queries for each operation which take depth and changelists and such into account, could we not just have a function would populates a simple 'work_list' with the paths upon which to operate, and then run the target query against that? It seems there are really two actions: produce the list of nodes to operate on, and then the actual operation itself. Separating those concerns feels like a way to both introduce some consistency, as well reuse the "figure out which paths to operate on" code. As for Bert's concerns about blowing out memory, we could put the list in a temporary table in the DB, and let SQLite worry about memory usage. This has the added benefit of making the operational queries of the form "update foo set bar='baz' where local_relpath in (select local_relpath from work_table)". Anyway, I'm not planning on implementing this just yet, and it isn't something which has to be done before 1.7, but I'm interested in thoughts on the approach. -Hyrum
