Comments
5 comments
-
It not absolutely clear what the correct behavior should be.
Should SQL Compare create an empty file called RedGate.ssc, like SQL Source Control does?
Or should SQL Compare just stop checking for RedGate.ssc altogether?
I would prefer the second option because it seems simpler from a user's point of view. -
SQL Compare has no code that reads from source control repositories: it uses the installed Source Control code. So the behavior of SQL Compare should be exactly equal to that of SQL Source Control.
-
I wasn't aware that SQL Compare actually used SQL Source Control in the background.
Thanks for explaining that.
The read behavior is consistent. Both SQL Source Control and SQL Compare fail to read a repo without a RedGate.ssc file.
The write behavior is not the same. SQL Compare can't write directly to an SVN repo.
When you set SVN as the target and go to the deployment wizard, your only option is to create a deployment script.
Would be great if the tools were more consistent.
Would it be possible to ignore the presence of RedGate.ssc?
If not, would it be possible for SQL Compare to write a RedGate.ssc file whenever it creates a set of scripts? -
I see your point and I am sorry this is not ideal, but the use case is that if you are putting scripts into source control, you would use SQL Source Control for that rather than generating a scripts folder and sticking it in source control using the tools that come with the VCS.
I can submit a suggestion to support this scenario. -
We use SQL Compare and TortoiseSVN together because we find they work better for us that SQL Source Control.
SSC gave us lots of confusing and difficult-to-reproduce SVN errors that just didn't happen when we used TortoiseSVN.
We'd be grateful if you could submit a suggestion to deal with the RedGate.ssc files in SQL Compare, either by ignoring them altogether or by creating them when writing a script folder.
Thanks for your help!
Add comment
Please sign in to leave a comment.
It works if you add an empty file called RedGate.ssc to the schema folder.
Follow these steps to reproduce the issue.
Repro steps
In steps 1-6 you create a Red Gate database schema folder and commit it to a new SVN repository.
This creates the condition to reveal the bug.
1. Create new SVN repo.
2. Create new SVN working copy.
3. Create new database with a single object.
4. Script out the database to the working copy.
5. Add new files to version control.
You can see from the output that sqlcompare created the RedGateDatabaseInfo.xml metadata file and a file for DummyProc.
sqlcompare did not create a file called RedGate.ssc (this matters in step 8).
6. Commit files to repository.
In steps 7-8 you try to read the schema folder direct from the SVN repository. SQL Compare rejects the folder.
The bug reveals itself in step 8.
7. Open a new project in the SQL Compare GUI.
Set the source type to "Source Control".
Set the source to "Direct from Source Control" and choose "Browse source control..." from the Repository list.
8. Set the source control system to Subversion (SVN).
Set the database repository URL to the repo URL file:///C:/Users/iain/DummyRepo (what you checked out in step 2).
Click Link.
SQL Compare shows an error dialog.
In steps 9-10 you try to read the schema folder from the working copy. SQL Compare accepts the folder.
9. Click OK then click cancel.
10. Set the source to "Scripts folder".
Set the scripts folder path to the working copy path C:\Users\iain\DummyWC (what you created in step 2).
SQL Compare accepts the path.
In steps 11-12 you commit a dummy file to let SQL Compare accept the folder direct from source control.
This provides a workaround for the bug in step 8.
11. Commit an empty file called RedGate.ssc to the repo.
12. Repeat steps 7 and 8.
Now SQL Compare accepts the folder direct from source control.
The repository field contains the URL file:///C:/Users/iain/DummyRepo (what you set in step 8).