updating DB with change type Drop

• 
  SQL Source Control should NOT be locking your files. I think it might be a setting on your Subversion server. Do you have TortoiseSVN installed? If so:
  1) Right click on C:\Users\justin.collazo\AppData\Local\Red Gate\SQL Source Control 0\WorkingBases\fc53bc1b-0e4b-4af9-9070-8aef7175a516\Tables\HumanResources.EmployeeDepartmentHistory.sql
  and select Properties
  2) Select the "Subversion" tab at the top
  3) Click the "Properties..." button near the bottom
  4) Is there a svn:needs-lock property? If so, remove it.
  5) Click OK to close the SVN properties window
  6) Click OK to close the file properties window
  7) Right click again and commit the change to Subversion (this is just committing the change that a lock is not needed on that file)
  
  Now, you should be able to commit the file from SQL Source Control with out getting this permission error. Please let us know if you still have any problems.
  
  You'll want to talk to your SVN administrator about the settings on your SVN server and see if you can remove the svn:needs-lock on your area. This way, you won't have this permission problem happen again. You'll need to remove the needs-lock property from all your existing files.

  StephanieHerr February 28, 2010 12:46

  - 0 +
• 
  I checked for svn:needs-lock as you suggested, but it wasn't there.
  
  I tried linking a new database to reproduce to problem since I had worked around it on the other database by clearing the read only property in windows explorer.
  
  I'm having the same problem with the new DB. I have the proper security rights in windows and SVN. The server settings are all default. Once the files are committed initially they're all set to read-only, not locked.
  
  I think my problem is for other projects (not using SQL Source Control) the files are usually checked out which removes the read only status and that's why I've never had a problem before.
  
  Nothing is set in the server's [auto-props] so read only must be default. Is there a setting to counteract this?

  justin.collazo March 01, 2010 17:31

  - 0 +
• 
  Hi Justin,
  
  Thanks for checking the svn:needs-lock properties. We're looking into other settings to counteract this. Our internal reference number is SOC-719 and you should be hearing from us soon.

  StephanieHerr March 02, 2010 06:50

  - 0 +
• 
  This issue was caused by a seperate SVN plug-in caused SVNSCC by Pushok Software. If you have this plug-in installed, use the following workaround:
  
  To get SQL Source Control and SVNSCC to work together, we need to configure SVNSCC not to modify attributes on the check outs used by SQL Source Control. As far as I can tell, the best way to do this is:
  
  1) Unlink all your SVN databases in SQL Source Control (Right click on each database, select 'Other SQL Source Control Tasks' then click 'Unlink database from source control.')
  2) Close SSMS
  2) Bring up a command prompt (Start+R, type in cmd and click ok)
  3) Type or copy and paste in the line below changing <username> to be your windows login, and press enter
  
  echo pushok::rwmon=skip-tree>"C:\Users\<username>\AppData\Local\Red Gate\.pushokprops"
  
  4) Run the 'SSC RW Monitor' (under Start->All Programs->Pushok Software)
  5) In the dialog that appears, click "Cleanup and Restart"
  6) When it has finished processing, SQL Source Control should work (You will need to relink your databases)

  StephanieHerr March 03, 2010 13:09

  - 0 +

Add comment

Please sign in to leave a comment.