Re: 1.7.3 next week-ish?

"roderich.schupp_at_googlemail.com" <roderich.schupp_at_googlemail.com>
writes:

> It's definitely an ordering problem, look at the whole series of operations:
>
> ...
> add file trunk/D/H/omega
> add file trunk/D/H/psi <--- the one with the bogus split props/text
> add dir branches
> add dir trunk/C
> add dir trunk/B/F
> ...
>
> "branches" starts while "trunk/..." has not finished yet.
> Also "trunk/B/.." continues though already "trunk/D/..." has started.

On my Linux box neon gives me:

DBG: dump_editor.c: 546: add_file trunk/D/H/omega
DBG: dump_editor.c: 669: change_file_prop 0xf76820
DBG: dump_editor.c: 669: change_file_prop 0xf76820
DBG: dump_editor.c: 669: change_file_prop 0xf76820
DBG: dump_editor.c: 669: change_file_prop 0xf76820
DBG: dump_editor.c: 669: change_file_prop 0xf76820
DBG: dump_editor.c: 719: apply_textdelta 0xf76820
DBG: dump_editor.c: 750: close_file 0xf76820
DBG: dump_editor.c: 546: add_file trunk/D/H/psi
DBG: dump_editor.c: 669: change_file_prop 0x1333820
DBG: dump_editor.c: 669: change_file_prop 0x1333820
DBG: dump_editor.c: 669: change_file_prop 0x1333820
DBG: dump_editor.c: 669: change_file_prop 0x1333820
DBG: dump_editor.c: 669: change_file_prop 0x1333820
DBG: dump_editor.c: 719: apply_textdelta 0x1333820
DBG: dump_editor.c: 750: close_file 0x1333820
DBG: dump_editor.c: 512: close_directory 0x1304148
DBG: dump_editor.c: 512: close_directory 0x1303780
DBG: dump_editor.c: 512: close_directory 0x13026b8
DBG: dump_editor.c: 432: add_directory branches

while serf gives me:

DBG: dump_editor.c: 546: add_file trunk/D/H/omega
DBG: dump_editor.c: 719: apply_textdelta 0x19be798
DBG: dump_editor.c: 669: change_file_prop 0x19be798
DBG: dump_editor.c: 669: change_file_prop 0x19be798
DBG: dump_editor.c: 669: change_file_prop 0x19be798
DBG: dump_editor.c: 669: change_file_prop 0x19be798
DBG: dump_editor.c: 669: change_file_prop 0x19be798
DBG: dump_editor.c: 750: close_file 0x19be798
DBG: dump_editor.c: 546: add_file trunk/D/H/psi
DBG: dump_editor.c: 719: apply_textdelta 0x1ff8798
DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
DBG: dump_editor.c: 669: change_file_prop 0x1ff8798
DBG: dump_editor.c: 750: close_file 0x1ff8798
DBG: dump_editor.c: 432: add_directory branches

Both of those orders work.

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.
Assuming our editor API allows multiple files to be open at the same
time then svnrdump probably needs to grow a dedicated file baton and use
that in close_file.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com