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
Received on 2011-04-22 23:04:13 CEST