Comments
11 comments
-
We're hoping to add this feature in an upcoming release. Are you looking for these objects to be put in source control and subsequently ignored, or is it important that these objects never make it into source control in the first place?
David Atkinson
Red Gate Software -
Hi David,
Thank you for your reply.
For me it would be ideal to match SVN's functionality, which is:
- The items are never put into source control.
- The source control does however have a register of the items that it is ignoring
Failing that, any way to ignore items would be useful.
The minimum useful functional requirements would be:
- allow items to be marked as ignored
- allow items to be un-ignored.
- for items marked as ignored, do not prompt to commit changes, do not check for updates
I hope this helps.
Regards,
Tim -
"Ignore this" implemented somehow ASAP - dealing with cross-domain Login mismatches and DB Role mismatches as well, and all the mismatches due to sp_MS% for every arbitrarilly named Replication byproduct means I really can't see the wood for the trees... I'll still use the add-in because it's workable, but with 50 and more objects to have to ignore every time I look at the offsite Production box you can imagine it gets OLD very quickly - and I've only been using SSC for THREE DAYS!
Please add my vote for swift inclusion of a workable "Ignore Feature".
Thanks for listening... -
Do you think that replication objects should be ignored in SQL Source Control by default? Would anyone want to source control these ever?
David -
Yes, please do ignore replication objects by default. The numbers following the SPs vary from instance to instance, so there's no real correlation there. In my case, we have but 5 PUB-SUBs in Production, only 2 in QA and development. Definitely care ZERO about Source Control for the generated objects, but I would like to source control each of the PUB-SUB CREATE scripts...
Thanks for asking, David. -
I agree with tscottIDG. We need to be able to ignore some database objects from source control. In my case I'm using tSQLt to create unit tests on database objects. I'm handling the units test separately in subversion and don't want them included as part of the databases source control but I can't ignore them...
-
Thanks for the request. This is a strong candidate for the next release (along with static data support).
I'm not familiar with tSQLt. Would this allow the unit test objects to be created in a separate linked database? This might be a workaround to avoid SQL Source Control from trying to commit them.
David -
David Atkinson wrote:Thanks for the request. This is a strong candidate for the next release (along with static data support).
I'm not familiar with tSQLt. Would this allow the unit test objects to be created in a separate linked database? This might be a workaround to avoid SQL Source Control from trying to commit them.
David
It is possible to place the tests in another database, but changing all my tests (which assume local db objects) would be tedious at best. -
I totally understand. Your other option is to wait until the first half of next year, which is when we plan to release SQL Source Control v2. Are you signed up to the Early Access list? This way you can try the features earlier and get the chance to give us feedback that can influence how the product is developed.
David -
David Atkinson wrote:I totally understand. Your other option is to wait until the first half of next year, which is when we plan to release SQL Source Control v2. Are you signed up to the Early Access list? This way you can try the features earlier and get the chance to give us feedback that can influence how the product is developed.
David
Is this implemented yet? Is there a trial version I can try that has this? -
Sorry, this isn't available just yet. We're working on it!
David
Add comment
Please sign in to leave a comment.
We have just started using SQL Source Control.
It does not seem to support for SVN Ignore functionality.
Is this correct?
When we have items in a specific DB that we do not want to manage, how do we tell SQL Source Control to ignore them and not prompt us to commit them each time?
Simple examples of things we do not want to manage are:
Common utility stored procs and functions that are managed in their own DB, and deployed to each client DB.
Thanks.