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

Error with commit/update on win32 in 5740

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: all
    • Fix Version/s: unscheduled
    • Component/s: unknown
    • Labels:
      None
    • Environment:

      Windows 2000

      Description

      Original message posted to dev-list:
      Repro steps on Win32:
      svn create repos
      svn co repos wc
      touch wc\test
      svn commit wc\test
      svn co repos wc2
      svn ren wc\test wc\test2
      svn commit wc\test (you will get the error below)
      svn up wc (no error)
      svn up wc2 (you will get the error below, sans the post-commit line)
      svn up wc2 (no error)
      
      Here's the error message copied from an actual repos.  Note the error is 
      caused by the text-base, not the file itself.  I will not be able to test 
      with HEAD for a couple of days.
      
      svn: Problem running log
      svn: Error bumping revisions post-commit (details follow):
      svn: in 
      directory 'C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test'
      svn: start_handler: error processing command 'committed' 
      in 'C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test'
      svn: Access is denied.
      svn: svn_io_remove_file: failed to remove 
      file "C:/source/main/GCASv2/Assemblies/GCAS.StaticTables.Test/.svn/te
      xt-base/StaticTable.cs.svn-base"
      
      Greg Stein <gstein@lyra.org> writes:
      > Last week or so, Karl removed a chmod() call the svn_io_remove() 
      function.
      > 
      > Previously, the function would *always* chmod the file to a writeable 
      state
      > before trying to remove it. That had some performance problems for a 
      few
      > reasons.
      > 
      > After the change, the assumption is that the caller would have to 
      know when
      > to chmod the file *before* calling the remove function.
      > 
      > It sounds like you've hit a case where somebody is not properly 
      chmod'ing
      > the file before calling remove...
      

      Original issue reported by jbowtie

        Attachments

          Issue Links

            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: