Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-1695

svn_fs__bdb_changes_fetch() fouls up change ordering

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: all
    • Fix Version/s: unscheduled
    • Component/s: src
    • Labels:
      None

      Description

      Though most (all?) Subversion clients seems to avoid doing so, it is quite
      possible to make changes to a filesystem transaction/revision-to-be in a
      non-depth-first way.  In fact, cvs2svn (through its use of the Subversion
      dumpfile  format) does just this when pruning directories.  For example, you
      might see in the 'changes' file:
      
         /path/to/dir/file1 - delete
         /path/to/dir/file2 - add
         /path/to/dir/file3 - delete
         /path/to/dir - delete
      
      Now, the 'changes'-table-accessing functions (both public and internal) return
      hashes keyed on path.  This allows no way to derive the true original change
      ordering.  Worse, users of those hashes typically *need* depth-first-ordered
      data (or at least *want* it).  Making the current hash data depth-first will
      re-order changes like the above such that the file operations occur *after*
      their parent directory is nixed.
      
      This is Bad.
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              cmpilato C. Michael Pilato
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: