Diffs when SSC changes order of rows in static table dump

bdw429sbdw429s Posts: 23
edited September 6, 2012 9:14AM in SQL Source Control Previous Versions
I have briefly searched the forums and Google and couldn't find this question/suggestion anywhere.

When viewing text diffs on static data for peer reviews or when merging two branches together in source control, updates to records often appear as deletes and inserts because the row was placed in a different location in the dump file when the update was committed. This can make it difficult to determine what data actually changed in the table.

Is there a way to have SSC order the data in the static table dumps by the columns used for comparison (typically the primary key)? This would ensure that the "same" record stays on the same line in the file.

Yes, I'm aware that SQL Server doesn't inherently guarantee any order of data, and that there is no functional difference. The issue is that when you are using a text-based VCS where line numbers are meaningful and text diffs are required to view deltas and resolve merge conflicts, it's kind of important that the diff engine be able to expect a consistent representation of the data.

And yes, if the primary key (or whatever columns are being used for comparison) are changed, that would be acceptable to show as a new record sorted to a different place in the file.

Thanks!

~Brad

Comments

  • +1

    Aside the "committed" rows of a specific check-in, everything seems to be already ordered by PK in the text file dump. The new & modified rows appear either at the top or at the bottom of the file.

    It does make branch merging a little nightmarish. Seems like keeping the order across all rows in the text dump would improve usability of branching merging with SQL Source Control.

    This should be made a feature request that we can vote on.

    Marc-Andre[/code]
  • Can anyone tell me where to submit this as a feature request?

    Thanks!

    ~Brad
  • Thanks for the posts here- as I understand it you want the format of our data files to be arranged differently (so they are in a simple comparison key ordering) to enable you to easily check them in a textual diff?

    If so, you can request the feature on our Uservoice page: see here

    Currently, we don't intend the files to be used in any way outside of our tools so the scenario you describe most likely hasn't been accounted for, but if lots of users also request the same feature it's something we can look into.
    Systems Software Engineer

    Redgate Software

  • James, thanks for the reply. I will certainly submit an enhancement request.

    For what it's worth, it was a Red Gate sales associate who actually suggested to me that branching and merging should be performed outside of SSC by a VCS tool. (Must have been over the phone as I can't find the E-mail) I would suggest that if Red Gate doesn't intend me to branch and merge with other VCS tools, that they build that functionality into SSC. :)

    In general though, I would caution against heading towards a proprietary solution that just so happens to use a few piece of another VCS system. I know you're trying to provide a turn-key solution but source control is built around the concept of human-readable text files which can be managed by any client. SSC should be embracing that or it will lose integration ability and nullify features if the underlying source control systems.

    Thanks!

    ~Brad
  • Enhancement requested:

    http://redgate.uservoice.com/forums/390 ... static-tab

    If you find this thread and agree, please click the link and vote :)
  • Thanks for logging the request
    bdw429s wrote:

    For what it's worth, it was a Red Gate sales associate who actually suggested to me that branching and merging should be performed outside of SSC by a VCS tool. (Must have been over the phone as I can't find the E-mail) I would suggest that if Red Gate doesn't intend me to branch and merge with other VCS tools, that they build that functionality into SSC. :)

    Yes - this would most likely be because we don't implement any branching of our own - the original workflow would be to have a separate SQL DB linked to each Branch you created.

    Once Migration scripts appeared it was found that these didn't work across-branches so when you merged changes back using whatever system you work with, the scripts created in the branch wouldn't run with the eventual merged set.
    Systems Software Engineer

    Redgate Software

  • Interesting. Is that because the migration script is tied to the specific revision numbers that is goes between and when you merge and commit between branches, your changes are committed with new revision numbers?

    I'm pretty certain some version systems store information about what revisions were merged and committed, but that would probably be unreliable for every source control system.

    What are your plans for finding a way to tie the migration script to the appropriate revisions that will still work across a merge?
  • I'm afraid I'm not currently sure - I think it's still under investigation to a point. As you say, we don't want to necessarily use anything that's specific to a certain system as it makes it a lot harder to then change later on for other source-control tools.
    Systems Software Engineer

    Redgate Software

  • We are checking the data file into source control. Not ordering the data file consistently will make it very difficulty to control the changes. Please add this feature. Thanks!
  • If you want this feature, please go vote here:

    http://redgate.uservoice.com/forums/390 ... static-tab
  • You got my vote on that. :)

    Thanks for posting.
Sign In or Register to comment.