Philip Martin <philip.martin_at_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
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
Received on 2012-02-08 11:10:10 CET