#11 Lots of: \"path_hash_test: NOT IN ORIG\"

[Valentin Haenel]

Hi,

When cloning a mid-sized repository, after a couple of days, I get the attached trace. Sorry, it seems like my buffer is not large enough for the entire output, and SF will not allow attachments bigger than 256k. So I had to gzip the file.

Anything else I could do to provide more debugging infos?

V-

[Valentin Haenel]

Gzipped partial trace.

[Jonas Gehring]

Hi Valentin,

That's really a lot of output... first, it would be useful to see the verbose log of revision 5708 (or the revision that ends up as 5708, I can't see the original revision in the output). If the paths mentioned by path_hash_test haven't been touched at all, there might be some other problem and it would be interesting to compare the SVN tree of the original revision to the output you've posted and check if they're equal.

Just ruling out some points of failure: Did you get any other error messages from rsvndump? Or did your temporary directory run out of space?

Thanks for reporting!
Jonas

[Valentin Haenel]

Hi Jonas,

strangely enough, the revision has no log entries.

zsh» svn log --verbose -r 5708
------------------------------------------------------------------------

As for the tmp space, I didn't wtach it. However I have /tmp and /var in the same partition as / on this machine and there is 571G avail. So I doubt that it will be that problem. Also, our sysadmin has asked me to not use rsvndump until further notice, because it was flooding the apache server logs to the point of filling up / on the server (23G). He does however acknowledge that its not malicious and will hopefully adapt the log level to be less verbose. An alterntiave, at least for testing would be to get a dump from the server, and then i could run rsvndump using a file:// url.

Also, I saw your commits on github just now. Is the problem fixed already?

best

V-

[Jonas Gehring]

Hi Valentin,

The recent commits to the github repository introduced features for version 0.6, so this specific bug should still be visible. If the issue is related to disk I/O, then the current version of the master branch might abort more early and with an error message.

It would be great if you we could hunt this one down. For quick testing, there's also a `--dry-run` flag which doesn't fetch text deltas from the repository (and should be much faster this way). The server logs will probably be filled, though.

Quite possibly, the empty commit log message caused the issue. Do you have the output of rsvndump for this revision still at hand? Or could you run `rsvndump --verbose --dry-run --incremental -r 5708` with a fresh version from github?

Thanks,
Jonas