I'm looking at fixing up svn_repos_dir_delta so that it can handle
updates where multiple arguments are passed via the client. The file
notes/multi-args.txt talks about the problem and its current planned
solution. Before I tackle this headfirst, though, I have a concern to
voice. Note the following segment from the multi-args.txt notes:
...
Also, the items should be done in the order given, so users on
slow links can put higher priority items first.
How do we do this?
Let TL be an apr_array_header_t representing the target list, in
the order it appeared on the command line. Assume that no
"../blah" paths are allowed in the targets.
1. Remove redundancies from the target list: all targets that
are descendants of some other target are removed.
...
Now, my concern. Consider the Greek Tree, and me on my futuristic
(albeit hypothetical) WAPtop computer, complete with 300 kbps
connection to the Internet. Now, I know from reading commit emails
for the past 6 hours (darned 200x120 pixel screen...) that Greg S. has
been making serious commits to all the files in and under A/D/. I'd
like to update my working copy so I'm not terribly out of date, but my
main concern is the file A/D/G/rho, which has some life-changing new
data in it.
If I run 'svn up A/D/G/rho A/D', Item 1 above will reduce this to just 'svn
up A/D', and here I go with a massive update that is very unlikely to
complete before the next biannual release of firmware for my WAPtop
happens (yes! Python 13.0 is supposed to supported in ROM in this
next update!).
In this simple case, sure I could run 'svn up A/D/G/rho' then 'svn up
A/D', and my priorities are respected. But in a larger example, it is
starting to look like I have to write a script or at least a
semicolon-delimited list of commands in order to get prioritized
update in a single command that I can leave running while I race my
hovercar around the block to get nutrient capsules (the food
cabinet--singular--is looking a little bare this late in the month).
Is it worthwhile to perform step 1 with attention to order (meaning,
redundancies are defined as targets that are descendants of some other
target *previously listed on the command line*)? If so, it means we
are not protected from updating a single file or dir more than once in
a single command (even though the second and subsequent updates for
such a node should be no-ops), and this has issues for the way in
which the update editor is driven. If not, I'll carry on with my
change (which currently includes adding an apr_array_header_t
TARGET_LIST argument to svn_repos_dir_delta which will be the list of
non-redundant targets that we actually want to update (with
SOURCE_PATH and TARGET_PATH now taking the role of the directory
common to all the items in the TARGET_LIST).
Comments? Am I on crack?
Received on Sat Oct 21 14:36:28 2006