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

cvs2svn crash, on half-broken non-atomic cvs commit

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Invalid
    • Affects Version/s: all
    • Fix Version/s: cvs2svn-1.0
    • Component/s: tools
    • Labels:
      None

      Description

      Ran cvs2svn (latest version as of r8536, post 0.37 release) on a large (32 MB as
      a tar.bz2) CVS repository and got a Python crash with traceback.
      
      I cut the repository down to a 45 kB tar.bz2 file by trimming files not near the
      area where the bug occurs, and still got the same traceback.
      
      The cut-down 43 KB repository is at:
      http://colossus.sourceforge.net/download/show-cvs2svn-bug.tar.bz2
      
      The full 32 MB repository is available if needed.
      
      SourceForge CVS, where this repository is hosted, was extremely overloaded and
      twitchy at the time of the commits that trigger the crash.
      
      The comment for the checkin of build.xml r1.102, where the traceback presumably
      happened, indicates that there was an attempt to delete some files from the
      test/ subdirectory in the same checkin.  Those files did not actually get
      deleted; the commit partially failed.  I hear atomic commits are a good idea.  :->
      
      The comment in get_metadata says:
      # by definition, the author and log message must be the same for all
      # items that went into this commit. therefore, just grab any item from
      # our record of changes/deletes.
      
      That sounds overly optimistic.  You're dealing with CVS.  CVS doesn't do atomic
      commits.  You really want to zoom in on the specific file that actually changed,
      rather than some other random file from the same commit, which may have not been
      updated.
      
      It appears that get_metadata tried to grab metadata not from build.xml r1.102
      (which is there), but from some other file in the same checkin version (I think
      either test/run or test/run.bat) r1.2.  Those files didn't get successfully
      changed, and were both still stuck at r1.1, so there's a KeyError looking for r1.2.
      
      Traceback message follows:
      -------------------------
      committing: Wed Jan  7 00:18:06 2004, over 0 seconds
          adding or changing 1.99 : 'trunk/build.xml'
          new revision: 273
      committing: Sat Jan 10 08:37:04 2004, over 992922 seconds
      Warning: commit spans more than 300 seconds
          adding or changing 1.100 : 'trunk/build.xml'
          new revision: 274
      committing: Sat Jan 10 08:37:04 2004, over 998795 seconds
      Warning: commit spans more than 300 seconds
          adding or changing 1.101 : 'trunk/build.xml'
          new revision: 275
      committing: Sat Jan 10 08:37:04 2004, over 1088045 seconds
      Warning: commit spans more than 300 seconds
      Traceback (most recent call last):
        File "/usr/local/bin/cvs2svn", line 2368, in ?
          main()
        File "/usr/local/bin/cvs2svn", line 2364, in main
          convert(ctx, start_pass=start_pass)
        File "/usr/local/bin/cvs2svn", line 2208, in convert
          _passes[i](ctx)
        File "/usr/local/bin/cvs2svn", line 2143, in pass4
          c.commit(dumper, ctx, sym_tracker)
        File "/usr/local/bin/cvs2svn", line 1866, in commit
          author, log, date = self.get_metadata()
        File "/usr/local/bin/cvs2svn", line 1836, in get_metadata
          author = rip.authors[rev]
      KeyError: '1.2'
      -------------------------------
      

      Original issue reported by dripton

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              subversion-importer Subversion Importer
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: