On Thu, Feb 9, 2012 at 10:45 AM, Philip Martin <philip.mar...@wandisco.com> wrote: > Johan Corveleyn <jcor...@gmail.com> writes: > >> DBG: dump_editor.c: 756: close_file 0112B188 >> DBG: dump_editor.c: 552: add_file trunk/D/H/psi >> DBG: dump_editor.c: 725: apply_textdelta 0112B188 >> DBG: dump_editor.c: 633: change_dir_prop 01150F00 >> DBG: dump_editor.c: 633: change_dir_prop 01150F00 >> DBG: dump_editor.c: 633: change_dir_prop 01150F00 >> DBG: dump_editor.c: 633: change_dir_prop 01150F00 >> DBG: dump_editor.c: 633: change_dir_prop 01150F00 >> DBG: dump_editor.c: 518: close_directory 01150F00 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 756: close_file 0112B188 > >> DBG: dump_editor.c: 552: add_file trunk/D/H/psi >> DBG: dump_editor.c: 725: apply_textdelta 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 675: change_file_prop 0112B188 >> DBG: dump_editor.c: 756: close_file 0112B188 > > So this is what I expected, the problem is the close_directory between > open_file and close_file. Because svnrdump doesn't implement a file > baton but instead just uses the edit baton to handle a single file, the > close_directory causes the file properties to be written early while the > text is written later in close_file. > > What I don't understand is how close_directory gets called between > open_file and close_file. When libsvn_ra_serf calls open_file it does > so from libsvn_ra_serf/update.c:handle_fetch and later in that same > close_file is called. How does close_directory get invoked between the > two? What is the callstack when close_directory is called?
I'll do some more experiments tonight. I'm not very experienced in debugging C code ... any hints on how to get a hold of the callstack easily? I'd think of setting a breakpoint there, but it would be best to do that with a conditional breakpoint somehow, to avoid having to resume a dozen times. But I'm still using Visual C Express 2008 here (the "free" version), and I'm not sure if that supports conditional breakpoints. And besides, I'm not sure what condition I could use ... Or can I simply write the callstack to stdout/stderr somehow at that point, without erroring out? What's still very mysterious about all this: - Why doesn't this bug present itself with mod_dav_svn from trunk. - Why does it only show up on Windows. But I like a little mystery now and then, so ... we'll see. -- Johan
