Exclude objects from versioning (svn:ignore)
As it is possible to exclude some files from SVN using file source control it would be great to remove some objects that we do not want to version - for example test procedures or users.
Our DBs often use NT security and are deployed into separate domains. Manually unchecking users is a pain as is avoiding the creation of roles with users specified.
There are times when some objects - table, view, stored proc, schema - are created, but I don't want to commit them to source control. It would be great if there were a way to inform the Redgate source control to ignore these items. Perhaps by schema?
We have certain objects that are created via SQL Compare from a parent database. Those are already under soure control under that database and kept up to date via SQL Compare. We do not want them track in the child table, only the child specific tables. So it would be useful to be able to flag individual objects as ignore.
It would be nice to be able to disable certain object types from being added to source control via some kind of settings dialog. Specifically I'd like to not include user object types in source control and disable them from being shown in the change type window.
Object Filtering now appears in SQL Source Control version 2.2!
For more information about the release, please see:
Just got the 2.2 version and found that the filters are database specific. Is there a way to set a "Default" filter that is used by all databases?
Also to my not on consistency. I was hoping to create a single default filter file and use it for both Source control and the SQL Compare GUI and SQL Command line. The GUI's are not compatible because of the parent nodes that define the server, instance, database name. Neither are comparable with SqlCompare's command line /ArgFile
AdminDavid Atkinson (Admin, Redgate) commented
@Chattabaugh - thanks for the request. We certainly hope that both tools can leverage the same information. If this doesn't work as expected by the time we get the early access builds out, do let us know!
It would be nice if this information was stored in an XML file that is consistent with the SQLCompare command line's /Argfile XML Schema. It would allow for consistent compare's during continuous integration.
The filter option would work for us providing there is a way to save the filter as a default. [for a linked database?] I would also like to see a way to propagate a "Standard" filter to all of our developer's systems. Either through copying a config file or stored with the RedGateDatabaseInfo.xml
I'd like to exclude permissioning changes from source control.
Eric Wahner commented
This is a must as we use your product and it wants to source control system replication procedures.
patrick feenstra commented
Yes!!!, a similar filter like sql compare would be great
Definitely workable. Excluding all SPs for replication and other-domain logins works fine in SQL Compare, so would be good in SSC, too.
If you introduce this ASAP and work on "other ideas" later, I'm fairly sure the community would be very appreciative...
I would like to see a situation where we only control what we put into control in the first place. Thus, we could add objects or remove them as we see fit no matter what type or name they may have.
Bob Fazio commented
That depends. What I am looking for is something along the lines of the following....
I have developers that create temporary procedures for a variety of reasons. Usually they will start with something like RAF_xxx RAF are my initials. I would like to ignore any procedures that begin with RAF_* so that we don't check-in procedures that really aren't ready for even a check in to source control.
Younes Abesi commented
Definitely, required for me. Especially those constraint auto generated names. I use TFS source control though.
I would really appreciate this feature for at least two reasons:
1) In some of our databases we have tables that are generated dynamically, so we don't want to keep a record of these tables.
2) In another database, we keep some temporary tables (not #tables, but permanent tables like "TRACE_TABLE_DELETE_ME" and "TEMP_DATA_TO_TEST_WITH".)
We have some DDL that creates schema objects dynamically; these particular objects, which fit a wildcard pattern, are essentially "non-static data" in and of themselves. Whatever I do at present, the database will show "changes pending" every time the normal use of this database updates these dynamic objects.
Jason Moore commented
Ditto for actually considering a .gitignore file if the source control is done through a Git repo.
If this tool had a feature to only include some objects, but not all, we would be more likely to consider a purchase. We cannot utilize and all-or-nothing tool within SQL Server. It would be a lot easier to phase in source control with a feature like this.
Yes, we would also like to be able to exclude items using the source control product, without this we cannot really use this as a source control option. You can do this with tortoisesvn in regards to flat file source control.
WT Jones commented
I would like this as well to exluded the vendor's code. We use a naming convention for our custom objects so a simple filter with wildcard support would work fine.
We also have SQLQueryNotification queues and stored procedures that would be nice to automatically exclude.
Alex Fekken commented
We have dev databases on different domains linked to the same repository. The only difference is in some Windows accounts behind the logins and not being able to "ignore" this is a big pain.
Of course we could use SQL Compare to (frequently) synchronise almost everything to and from a single source controlled database but that would not really be the "Dedicated database development" that you recommend.
Bruce Warren commented
I would like to exclude certain database objects from the source control system.
In particular, assemblies & serice broker objects.
We have an application that dynamically creates service broker queues, services etc which generates clutter in the source control system.