What causes "Unable to parse entry!" in phacility/phabricator?

Run the failing svn ls --xml command by hand and compare the entry text against the regex

phacility/phabricator · error · Exception

Unable to parse entry!

Error message

Unable to parse entry!

What it means

The hand-rolled parser for svn ls --xml joins the lines of each <entry> element and matches a fixed regex expecting kind="(file|dir)"><name>...</name> with an optional <size> block (PhabricatorRepositorySvnCommitChangeParserWorker.php:678-695). If the joined entry text does not match - different attribute order, extra attributes, CDATA or entity-heavy names - it throws 'Unable to parse entry!'.

Source

Thrown at src/applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php:691

    return $map;
  }

  private function parseRecursiveListFileData($file_path) {
    $map   = array();
    $mode  = 'xml';
    $done  = false;
    $entry = null;
    foreach (new LinesOfALargeFile($file_path) as $lno => $line) {
      switch ($mode) {
        case 'entry':
          if ($line == '</entry>') {
            $entry = implode('', $entry);
            $pattern = '@^\s+kind="(file|dir)">'.
                       '<name>(.*?)</name>'.
                       '(<size>(.*?)</size>)?@';
            $matches = null;
            if (!preg_match($pattern, $entry, $matches)) {
              throw new Exception(pht('Unable to parse entry!'));
            }
            $map[html_entity_decode($matches[2])] =
              $this->getFileTypeFromSVNKind($matches[1]);
            $mode = 'entry-or-end';
          } else {
            $entry[] = $line;
          }
          break;
        case 'entry-or-end':
          if ($line == '</list>') {
            $done = true;
            break 2;
          } else if ($line == '<entry') {
            $mode = 'entry';
            $entry = array();
          } else {
            throw new Exception(
              pht(

View on GitHub (pinned to 5720a38cfe)

Solutions

Run the failing svn ls --xml command by hand and compare the entry text against the regex
Pin svn to a compatible version on the daemon host
Replace the regex parse with a real XML parser locally and report the incompatibility upstream

Defensive patterns

Strategy: try-catch

Validate before calling

// Validate the entry shape with the production regex before relying on it:
//   svn ls --xml <repo-url> | head -20
// Entries must match kind="(file|dir)"><name>...</name>[<size>...] exactly.

Try / catch

try {
  $map = $this->parseSVNListXML($file_path);
} catch (Exception $ex) {
  // Entry did not match the hardcoded regex: capture the raw XML for the
  // report, pin/patch the svn client; retrying is pointless until then.
  phlog(file_get_contents($file_path));
  throw $ex;
}

Prevention

Pin the svn client version and verify its ls --xml output after any upgrade
Avoid locale changes on daemon hosts that alter XML entity encoding
Keep the raw svn output in logs when parser errors occur, to diff expected vs actual formats

When it happens

Trigger: An svn client version emitting entries whose attribute order or content differs from the regex; names containing characters that break the lazy pattern; whitespace or formatting changes in the XML.

Common situations: Upgrading the svn binary or server changes the emitted XML shape; locale/encoding settings altering entity encoding of file names.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/d884789d0934f773. Report an issue: GitHub.