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

'switch' does not reset the native file system's read-only attribute within a WC




      If your WC has a file with the svn:needs-lock property set and you then switch
      your WC to a branch where that file does not have that property.  The property
      is removed in the WC but the read-only attribute is not removed from the file.
      This causes problems in Subclipse, and somewhat also TortoiseSVN, since we both
      decorate files based on the read-only attribute.  In the case of Subclipse, the
      presence of the read-only attribute causes Eclipse to present the user with the
      Subclipse Lock UI -- a good thing.  However, we are then relying on the svn lock
      command to remove the read-only attribute, which it doesn't in this case.  It
      would be nice as a fail-safe if it could do that.
      This should be reproduction recipe.  I did it on Windows, so this may not be
      exactly right.
      svn mkdir -m "" url://repos/trunk
      svn co url://repos/trunk test_wc
      cd testwc
      touch foo
      svn add foo
      svn ci -m ""
      svn copy -m "" . url://repos/branch 
      svn propset svn:needs-lock foo
      svn ci -m ""    
      svn switch url://repos/branch
      At this point, foo will not have the property, but it will be read-only.
      Again, as an additional requuest it would be nice at this point if:
      svn lock foo
      Would remove the read-only attribute even though the svn:needs-lock property
      does not exist.


        1. 1_patch.txt
          1 kB
          Daniel Rall
        2. 2_patch.txt
          3 kB
          Daniel Rall
        3. 3_stack.txt
          3 kB
          Daniel Rall
        4. 4_2306.recipe.sh
          2 kB
          Daniel Rall
        5. 5_patch.txt
          3 kB
          Daniel Rall



            Unassigned Unassigned
            markphip Mark Phippard
            0 Vote for this issue
            2 Start watching this issue