Re: 1.7.3 next week-ish?

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
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