Support source control integration with SSMS Solutions/Projects
We have SSMS solutions that contain only our stored procedures, functions, and views. We have these solutions in Subversion repositories and are currently using TortoiseSVN to manage changes. It would be great if this tool (or a similar one) would support Subversion integration with SSMS much like the existing support for Visual Source Safe.
It could be much like VisualSVN but for Management Studio instead of Visual Studio.
anonymous
shared this idea
-
James
commented
Up until last week this has never been a problem for me. I used the SSMS Visual Studio MSSCCI provider for TFS/VSTS and it kept my solutions and tests while RedGate did the Database. And now I have SSMS 2016 and POW MSSCCI has gone and I read the instructions for getting them back and they were comic. And I really would like to be able to push my SSMS solutions into source control. Help me RedGate!
-
Doug.T
commented
If you use Visual Source safe you have your SQL Project under source control. Not so with SVN.
Everything in the Object explorer that is in the DB is fine.
Everything in the Solution Explorer is totally ignored – SVN wise.It is as if the red gate code has no knowledge of an SQL Project (a file system activity that happens to connect to a database that it does know about).
It is as if your DB (that is green) is the only thing that matters, any Scripts ( eg as part of a MS Build, MS Test, MS Deploy or Process pipeline are ignored) so there is the exposure/vulnerability of the other half of your project. -
jrummell
commented
That's something I've been pondering. There may be another issue for us. We only have two copies of the database, one for development and one for production. The database is just too big for each developer to have their own local copy. If multiple developers could use SQL Source Control on the same database connection (with svn:ignore), then we would prefer to do that. Otherwise, we would probably have to stick with SSMS solutions.
-
That makes sense! I understand why you suggested svn:ignore now. :-) Would you prefer one over the other (svn:ignore vs supporting SSMS solutions)? We'll have to think about this some more...
-
jrummell
commented
Perhaps. In my scenario, which may not be all that common, I'm writing views and stored procedures in our ERP database so that we can compose meaningful reports. Our ERP database has ~40,000 tables, and we don't care about the schema for 99% of these. We only care about the few that we've added. So if we could use SQL Source Control for only selected database objects, then we wouldn't need SSMS solutions.
-
The whole idea behind SQL Source Control is to allow db developers to work directly on their db objects. All you have to do is right-click on a stored procedure, modify, and execute this in SSMS. Once you have tested it and are happy, then you commit this to Subversion. There's no need to save the file anymore. Would having SQL Source Control replace SSMS solutions?
-
jrummell
commented
VisualSVN nor AnkhSVN will work because Management Studio doesn't officially support the Visual Studio add-in model. I've already submitted feature requests to both projects =).
-
jonathanallen69
commented
I have never tried it but wouldnt VisualSVN do this?
-
jrummell
commented
Or perhaps you could ignore (i.e. svn:ignore) certain objects?
