SC can't read new repo: "Unable to find a RedGate.ssc file"

isme

SQL Compare fails to read a schema folder it has created if you try to read it direct from an SVN repository.

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.

$ svnadmin create DummyRepo

2. Create new SVN working copy.

$ svn checkout file:///C:/Users/iain/DummyRepo DummyWC
Checked out revision 0.

3. Create new database with a single object.

$ sqlcmd -Q "CREATE DATABASE DummyDB;"

$ sqlcmd -d DummyDB -Q "CREATE PROCEDURE DummyProc AS RETURN 1;"

4. Script out the database to the working copy.

$ sqlcompare /database1:DummyDB /makescripts:DummyWC
SQL Compare: activated, edition: professional, serial number: XXX-XXX-XXXXXX-XXXX
SQL Compare Command Line V10.5.0.611
======================================================================================================================
Copyright © Red Gate Software Ltd 1999-2013

Creating folder of scripts 'C:\Users\iain\DummyWC' from database 'DummyDB' on '(local)'...
OK

5. Add new files to version control.

$ svn add DummyWC/*
svn: Skipping argument: E200025: 'DummyWC/.svn' ends in a reserved name
A         DummyWC\RedGateDatabaseInfo.xml
A         DummyWC\Stored Procedures
A         DummyWC\Stored Procedures\dbo.DummyProc.sql

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.

$ svn commit DummyWC --message "Initial commit. Folder contains one DummyProc and RedGateDatabaseInfo.xml"
Adding         DummyWC\RedGateDatabaseInfo.xml
Adding         DummyWC\Stored Procedures
Adding         DummyWC\Stored Procedures\dbo.DummyProc.sql
Transmitting file data ..
Committed revision 1.

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.

Database location isn't valid

Unable to find a RedGate.ssc file at the database location specified

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.

Red Gate database schema found

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.

$ copy NUL DummyWC\RedGate.ssc
        1 file(s) copied.

$ svn add DummyWC\RedGate.ssc
A         DummyWC\RedGate.ssc

$ svn commit DummyWC --message "Add empty file RedGate.ssc to let SQL Compare read from SVN."
Adding         DummyWC\RedGate.ssc
Transmitting file data .
Committed revision 2.

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).

isme

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.

Brian Donahue

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.

isme

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?

Brian Donahue

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.

isme

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!