Philip Martin <philip.mar...@wandisco.com> writes: > The dump editor used by svnrdump doesn't use an explicit file baton, it > simply uses the editor baton to collect the data for the "current" file.
To a certain extent this means that svnrdump works by accident. The editor API allows a driver to open multiple files and hold them open when the parent directory is closed; this is how postfix text deltas are delivered. svnrdump would fail if a driver worked this way. This is a problem that affects both trunk and 1.7.x. So that looks like a real bug, and I suppose it's possible that fixing svnrdump to allow multiple files to be open would fix the 1.7.x FAIL. However I still don't understand the current FAIL. When serf calls svnrdump's add_file callback it does so from libsvn_ra_serf/update.c:handle_fetch and that will always call svnrdump's close_file as well. So I really don't see how serf could get an open_directory call between add_file and close_file. Could handle_fetch be getting some sort of error that causes it to skip close_file? What do we do about 1.7.3? Ideally we would investigate the Windows failure further but resources seem to be limited. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
