Support for SVN Ignore functionality?

tscottIDGtscottIDG Posts: 3
edited February 21, 2011 7:35AM in SQL Source Control Previous Versions
Hi,

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.
· Share on Twitter

Comments

  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    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
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • tscottIDGtscottIDG Posts: 3
    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
    · Share on Twitter
  • PDinCAPDinCA Posts: 642 Silver 1
    "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...
    Jesus Christ: Lunatic, liar or Lord?
    Decide wisely...
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    Do you think that replication objects should be ignored in SQL Source Control by default? Would anyone want to source control these ever?

    David
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • PDinCAPDinCA Posts: 642 Silver 1
    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.
    Jesus Christ: Lunatic, liar or Lord?
    Decide wisely...
    · Share on Twitter
  • dmasciangelodmasciangelo Posts: 3
    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...
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    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
    Product Manager
    Redgate Software
    · Share on Twitter
  • dmasciangelodmasciangelo Posts: 3
    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.
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    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
    Product Manager
    Redgate Software
    · Share on Twitter
  • devavratdevavrat Posts: 1
    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?
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    Sorry, this isn't available just yet. We're working on it!

    David
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
Sign In or Register to comment.