How can we improve SQL Source Control?

Support SVN "Id" keyword

We already maintain our database scripts in SVN (using Tortoise), and are very keen to change over to your product.

We include the SVN keyword $Id$ in a comment at the top of every object file. When we commit, SVN automatically updates this to provide the Date, Author and Revision number of the last commit. This means that we're easily able to see which version of a particular stored procedure or function is in a client's database.

SQL Source Control doesn't like this though. When I commit a change through SQL Source Control, the Id is updated by SVN, and SQL Source Control reports that my stored procedure has changed.

Cheers,
Andrew

79 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Andrew TregonningAndrew Tregonning shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Red Gate AdministratorAdminRed Gate Administrator (Admin, Red Gate) responded  · 

    We’re currently not planning to support this for v1. Would you be ok to remove the $id$ keyword for now?

    We’ll have to see how many votes this suggestion gets…

    Internal reference number: SOC-113

    8 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • MHMH commented  ·   ·  Flag as inappropriate

        Not only keyword $Id but also all other keywords (Date, Revision, Author, ...). Is this subject to be supported in the next SQL Source Control versions?

      • Anonymous commented  ·   ·  Flag as inappropriate

        Did this functionality ever get implemented? I've just tried SQL Source Control v 3.2.0.27 and have the following problem:

        1) Add keyword to stored procedure comment block
        2) Commit change
        3) SVN expands keyword post-commit
        4) SQL Source Control doesn't update database with expanded keyword data
        5) Immediately after committing change, SQL Source Control compares database to repo and sees the expanded keyword data as a change, so flags as a change that needs to be committed.

        Repeat ad infinitum as the database copy is never updated and always contains the un-expanded keyword.

        In addition, if I then try and change the stored procedure in the database, SQL Source Control sees the expanded keyword on the repo as a conflicting change and the universe implodes.

        Basically, it's broken. Did I not set things up correctly?

      • SQLSourceControlUserSQLSourceControlUser commented  ·   ·  Flag as inappropriate

        We had to remove all SVN keywords because after commit, the procedure/view always is marked as "changed" again. It seems that the keywords get updated AFTER the commit. It should first get updated and then committed. We had to remove all SVN keywords again to finally get "clean" commits. :-(

      • Jose FortunaJose Fortuna commented  ·   ·  Flag as inappropriate

        Wouldn't this be a simple update to latest after commit? This is very useful. At the moment I just undo the "edit" and it refreshes the version from SVN!

      • Josef RichbergJosef Richberg commented  ·   ·  Flag as inappropriate

        This is a must for sql objects. How else can I determine what is in production vs what is in development vs what is in source control?

      • lakelandlakeland commented  ·   ·  Flag as inappropriate

        I'd certainly not wait for this feature but I'd find it pretty useful.

        Currently I have some developers writing changes in the comments of SPs and others adding comments in the commit log so I have to look in both places to get a full picture.

      • phrrngtnphrrngtn commented  ·   ·  Flag as inappropriate

        SVN keywords are a 'must have' for us too. Ideally, once the changes have been checked into subversion, the tool would update the definition on the dataserver. As an alternative, I would be OK with some kind of integration in with SQL Server extended properties so that the the property values were updated with the keyword values even if the object text was not.

      • Andrew TregonningAndrew Tregonning commented  ·   ·  Flag as inappropriate

        We find the $Id$ keywords very useful, so would probably just wait for a future release of SQL Source Control that supports them.

        Cheers,
        Andrew

      Feedback and Knowledge Base