Backup a database which is under revision control (with SQL Source Control), modify an SP and commit it. Then restore the DB (rolls back the SP). Source Control see the changed SP and allows me to commit it, but Get Latest doesn't.

Project management issue tracking software (Gemini, JIRA etc) use BugID to link checkins against issues. This allows for a managers to oversee progress on issues and other things (eg: risk of change, code review etc). The SVN BugID (a checkin property) is how a development code checkin is linked to an issue. Add this, and I can integrate our solutions easier at a CMMI level 3-5

At current we have SQL source control running in a remote environment. However, a DB - SVN link is stored for each user account, and is not transparent to the other developers.

Worse yet, with each developer having their own workcopy in their local profile, the same data will be duplicated several times. Also: conflicts will arise since each workspace updates on its own, while the DB might already be updated from another workspace.

Therefor: Suggest to keep 1 workspace per DB, to prevent issues of multiple workspaces or repositories linked to the same DB.

I recently connected to my database as a new user with minimal privileges (just data_reader). Later I went to SQL Source control to see changes (forgetting I was logged in as the restricted user) and the output was scary - every SP was marked as deleted and most tables were marked as edited (text replaced with 'encrypted').

I didn't have the courage to hit commit just to see what happened - it was too scary seeing my entire database marked for deletion!

We already maintain our database scripts in SVN (using Tortoise), and are very keen to change over to your product.

We include the SVN keyword $Id$ in a comment at the top of every object file. When we commit, SVN automatically updates this to provide the Date, Author and Revision number of the last commit. This means that we're easily able to see which version of a particular stored procedure or function is in a client's database.

SQL Source Control doesn't like this though. When I commit a change through SQL Source Control, the Id is updated by SVN, and SQL Source Control reports that my stored procedure has changed.

Cheers,
Andrew

We already maintain our database scripts in SVN (using Tortoise), and are very keen to change over to your product.

We include the SVN keyword $Id$ in a comment at the top of every object file. When we commit, SVN automatically updates this to provide the Date, Author and Revision number of the last commit. This means that we're easily able to see which version of a particular stored procedure or function is in a client's database.

SQL Source Control doesn't like this though. When I commit a change through SQL Source Control, the Id is updated by SVN, and…

Not everyone will want to use SQLCompare for continuous integration for various reasons. Adding an option to include an if exists...drop statement with certain types of objects means that all scripts can still be CREATE scripts while allowing for other CI implementations.

For now, you may be able to use a batch file that executes SQL and drops the objects you want re-created before using the SQL Compare Command Line API. Since the objects are dropped, the synch script will generate CREATE scripts instead of alter.

If you wanted to create everything from scratch, you could drop and recreate the database, which would generate all CREATE scripts.

I've just had a stored procedure that I haven't modified come up as having changes to commit. The Previous and Next buttons are disabled as though there are no differences and I can't see any differences. Yet it repeatedly comes up as an object with changes. Huh?

I have a database managed in SVN. On my development machine I deleted it and then recreated it with the same name. RedGate maintained the link to SVN despite the drop (ok, doesn't bother me) but it then marked every object in the database as being in conflict

This is a known issue. I’m glad you’re ok that the link to SVN is maintained. The problem is the underlying working folder is out of date.

WORKAROUND:
Option 1)
On the setup tab, unlink the db from source control. If you still want to manage the db in SVN, then relink.

Option 2)
Use the Commit or Get Latest tabs to decide if you want to keep the version in your db and commit it or take the version that is in source control. After making a decision using the radio buttons in the differences pane at the bottom of these tabs, you must then click the Commit and/or Get Latest buttons to actually perform the action.

HINT: You can select multiple rows by selecting 1 row and then hitting Ctrl-A or select the top row and then hold the shift key down and select the last row with your mouse. The decision to Keep Mine or Take Theirs will then apply to all the hightlighted rows.

I hope this helps!

This is a known issue. I’m glad you’re ok that the link to SVN is maintained. The problem is the underlying working folder is out of date.

WORKAROUND:
Option 1)
On the setup tab, unlink the db from source control. If you still want to manage the db in SVN, then relink.

Option 2)
Use the Commit or Get Latest tabs to decide if you want to keep the version in your db and commit it or take the version that is in source control. After making a decision using the radio buttons in the differences pane at the bottom of these tabs, you must then click the Commit and/or Get Latest buttons to actually perform the action.

HINT: You can select multiple rows by selecting 1 row and then hitting Ctrl-A or select the top row and then hold the shift key down and select the…

We use SVN with the config "*.* = svn:needs-lock=*" to automatically lock files on all our repositories (parameter in the config file of SVN on the computer of the developer).
So a source file can be modified by only one developer at a time.
It looks it’s a problem with SQL Source Control because the files in the local directory of the working databases are in read only.
When I commit a change, I have the message “Do not have permissions to modify the file C:\Documents and settings\...\Stored Procedures\dbo.PS_select.sql”.
The commit is stopped.
Of course, we would like to stay in lock mode with Subversion...

We use SVN with the config "*.* = svn:needs-lock=*" to automatically lock files on all our repositories (parameter in the config file of SVN on the computer of the developer).
So a source file can be modified by only one developer at a time.
It looks it’s a problem with SQL Source Control because the files in the local directory of the working databases are in read only.
When I commit a change, I have the message “Do not have permissions to modify the file C:\Documents and settings\...\Stored Procedures\dbo.PS_select.sql”.
The commit is stopped.
Of course, we would like to stay…

We currently do not support lock or exclusive checkouts (lock-modify-unlock model). We are supporting a copy-modify-merge model.

In order to use SQL Source Control, you’ll need to use this model for now until we implement locking/exclusive checkouts in a future release.

To do this, undo the change to the Subversion configuration file, remove the needs-lock property from any file in the repository, manually svn update the WorkingBases directory, unlink and then relink the db in SSMS.

Depending on your OS, related files can be found in:
C:\Documents and Settings\\Local Settings\Application Data\Red Gate\Logs\SQL Source Control 0
or
C:\Users\\AppData\Local\Red Gate\Logs\SQL Source Control 0

1) Right click on WorkingBases\\Stored Procedures\dbo.PS_select.sql
and select Properties
*You can find the which corresponds to your db by looking in the LinkedDatabases.xml file.
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.

We currently do not support lock or exclusive checkouts (lock-modify-unlock model). We are supporting a copy-modify-merge model.

In order to use SQL Source Control, you’ll need to use this model for now until we implement locking/exclusive checkouts in a future release.

To do this, undo the change to the Subversion configuration file, remove the needs-lock property from any file in the repository, manually svn update the WorkingBases directory, unlink and then relink the db in SSMS.

Depending on your OS, related files can be found in:
C:\Documents and Settings\\Local Settings\Application Data\Red Gate\Logs\SQL Source Control 0
or
C:\Users\\AppData\Local\Red Gate\Logs\SQL Source Control 0

1) Right click on WorkingBases\\Stored Procedures\dbo.PS_select.sql
and select Properties
*You can find the which corresponds to your db by looking in the LinkedDatabases.xml file.
2) Select the “Subversion” tab at the top
3) Click the “Properties…” button near the bottom
4) Is there a svn:needs-lock property?…

This sounds like a problem we’ve seen before. Do you have Microsoft Security Essentials installed? If so, this could cause a problem when committing a large number of objects, which is usually the case when first committing an existing database to source control. Your workaround of doing a smaller partial commit seems to fit this expected behaviour.

To get around this, please configure Security Essentials to exclude LOCALAPPDATA\Red Gate\SQL Source Control 0\ from live protection.

I want an option for all scripts and directories to have no whitespace in their file names. For example "Database Triggers" would be "DatabaseTriggers". This makes working manually with the scripts from the command line much easier.