Programmatically Link DB to SVN

Reidy · March 3, 2012 7:18AM

Hi

We are currently reviewing the Source Control product as part of an automate developer deployment center.

We would like to be able to programmatically link a DB to source control, rather than relying on the adviser doing this. Is this possible? If so, how?

Thanks
David

peter.peart · March 5, 2012 9:13AM

Thanks for your post. Unfortunately, this isn't something that you're able to do at the moment, however I can add a feature request for you.

Would you mind letting me know though why exactly it is that you wish to do this?

Pete

Reidy · March 5, 2012 9:25AM

Hi,

We are developing a developer dashboard. So, the developer is due to start a new work item. The dashboard would provision the local working envrionment by creating a new branch within SVN for the application code, it would also restore a localised version of the database from a backup.

The intention is to then link the database to SVN so that other developers can then contribute to the same work item.

It would be ideal if we could fire a command line argument into SQL management studio which would essentially say. "Here's a new database, it needs linked to this SVN URL, now automatically commit the initial schema as is".

Thanks
David

David Atkinson · March 5, 2012 9:31AM

I like this idea.

In theory this might be possible because we already store the source control repository URL in the database extended property, so it has all the information it needs to do the link. However, automatically linking for all users who have SQL Source Control installed would probably not be the desired outcome, as only 'dev' instances should be linked. However, we might be able to pop up a question to the user when the SQL Source Control screen is loaded and ask the user once if they want to link, and if they accept, the link would happen automatically. Would this more or less be what you're hoping for?

David Atkinson
Product Manager
Red Gate

Reidy · March 5, 2012 9:37AM

Thanks for a quick reply.

Yes it's more or less what we're looking for, the only issue being that in our situation we wouldn't necessarily want to give the user the ability to cancel the procedure.

I did try importing the RedGate dll's into Visual Studio, and found that there appears to be methods available which would create the link... however, didn't manage to get these working.

Thanks
David

David Atkinson · March 5, 2012 9:41AM

Yes, good point.

The prompt could simply ask the user if they want to enable source control for that database. Confirming this will do the link (turning the database green). The prompt could simply exist permanently on the SQL Source Control screens.

The specific time the user shouldn't be linking is if they select a production database, as linking adds a small amount of load on to the server, which the DBA may not have agreed to. Mind you, this wouldn't be disastrous as the remedy is to simply unlink the database, which is a trivial operation.

David

Reidy · March 5, 2012 9:57AM

Yes, in our situation our developer dashboard would only be available on local development machines. Ideally, we wouldn't even want to ask the user, we just want it to happen. If we could make the process invisible to the user, even better!

While I have your attention, are there any plans to introduce the ability to create custom migration scripts which don't need to be linked to schema changes? So I could say upgrading from v1 to v2 is to simply run an update to data held within a table. (not having this is a major issue to how we would like to use the RedGate Source Control in conjuntion with our internal processes).

Thanks
David

David Atkinson · March 5, 2012 10:07AM

Maybe we can provide an option that makes it happen automatically. We'd have to be sure that this isn't going to inadvertently cause production databases to link...

I think the only safe way is to get the user to agree to link. We can make this trivially easy prompting the user when the user tries to perform any source control operation on the database.

Regarding adding migration scripts for non-schema changes, please vote for this here:

http://redgate.uservoice.com/forums/390 ... to-any-dat

The workaround is to add these before or after schema changes, but we are aware that this isn't ideal. Migration scripts at the moment have a from and to revision, which have to be different values. What is required is for us to allow a migration script between two revisions.

David

Reidy · March 5, 2012 10:34AM

In our situation we could ensure a production DB isn't linked as developers don't have direct access to the productin DB. Understand this may not be the case for everyone, so having a prompt wouldn't be the end of the world.

I have voted as requested, do you have any idea on expected timescales for this? An alternative we are looking at is making a trivial schema change (such as changing the data type of a column on a dummy table), then using this script for data updates, as you say, this is far from idea.

It would also be nice to name migration scripts manually to make it more relevant.

Thanks
David

David Atkinson · March 5, 2012 10:43AM

I can't commit to a date, but it's well within the top 20 backlog items, so I'm hopeful that it won't be too long before we address it.

Improvements like this will help *all* users get up and running with minimal hassle, and we recognize that this has to be a very positive thing for adoption of our tool!

David

Programmatically Link DB to SVN

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk