"roderich.sch...@googlemail.com" <roderich.sch...@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
