Diffs when SSC changes order of rows in static table dump
bdw429s
Posts: 23
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
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
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]
Thanks!
~Brad
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.
Redgate Software
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
http://redgate.uservoice.com/forums/390 ... static-tab
If you find this thread and agree, please click the link and vote
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.
Redgate Software
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?
Redgate Software
http://redgate.uservoice.com/forums/390 ... static-tab
Thanks for posting.