I have a pretty exhaustive repository that I built svnlib against, with all sortsa different kinds of funny revisions in it that suss out most of subversion's dark corners. As of the most recent version of svnlib, the only thing it still burps on is this check in logparser.inc (lines 208-11 in my current version, as helpful as that is):

          if ($this->actions[$other_path]['action'] & VERSIONCONTROL_SVN_ACTION_DELETE
              && $action['source_item']['rev'] == ($action['current_item']['rev'] - 1)
              && $other_path == $action['source_item']['path']) {

Some revision scenarios can cause $this->actions[$other_path]['action'] to be an undefined index, meaning that the basic rev output handler didn't populate that data. So the aggregate logparser burps. It may be harmless, but we may be losing data; in either case, we need to figure out what revision data is causing the burp. I'm putting this issue up to a) identify it as a known problem, b) offer up to anyone who feels like investigating to figure out the problem with the data, and more than likely c) as a reminder to myself so that I take care of it at some point.

Comments

sdboyer’s picture

sdboyer commented
Status: Active » Fixed

Neeevermind, fixed! Was a problem with whether or not rawurlencode() was being called in the info parser. Yes, we love svn, which outputs strings in raw form in its log xml output, but url-encoded form in its info xml output...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.