Diffs when SSC changes order of rows in static table dump

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace, andy.campbell.smith

Diffs when SSC changes order of rows in static table dump

Postby bdw429s » Thu Aug 09, 2012 6:30 pm

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
bdw429s
 
Posts: 20
Joined: Thu Aug 09, 2012 4:05 pm
Location: Kansas

Postby maturmel » Mon Aug 13, 2012 3:20 pm

+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]
maturmel
 
Posts: 24
Joined: Tue Jan 25, 2011 9:16 pm

Postby bdw429s » Wed Aug 15, 2012 11:06 pm

Can anyone tell me where to submit this as a feature request?

Thanks!

~Brad
bdw429s
 
Posts: 20
Joined: Thu Aug 09, 2012 4:05 pm
Location: Kansas

Postby james.billings » Thu Aug 16, 2012 9:30 am

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.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby bdw429s » Thu Aug 16, 2012 5:36 pm

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
bdw429s
 
Posts: 20
Joined: Thu Aug 09, 2012 4:05 pm
Location: Kansas

Postby bdw429s » Thu Aug 16, 2012 5:44 pm

Enhancement requested:

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

If you find this thread and agree, please click the link and vote :)
bdw429s
 
Posts: 20
Joined: Thu Aug 09, 2012 4:05 pm
Location: Kansas

Re:

Postby james.billings » Fri Aug 17, 2012 8:02 am

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.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby bdw429s » Fri Aug 17, 2012 4:33 pm

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?
bdw429s
 
Posts: 20
Joined: Thu Aug 09, 2012 4:05 pm
Location: Kansas

Postby james.billings » Mon Aug 20, 2012 8:37 pm

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.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

+1

Postby chunxing.shen@gmail.com » Tue Aug 21, 2012 10:17 pm

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!
chunxing.shen@gmail.com
 
Posts: 1
Joined: Thu Jul 14, 2011 10:32 pm

Postby bdw429s » Tue Aug 21, 2012 10:23 pm

If you want this feature, please go vote here:

http://redgate.uservoice.com/forums/390 ... static-tab
bdw429s
 
Posts: 20
Joined: Thu Aug 09, 2012 4:05 pm
Location: Kansas

Postby maturmel » Thu Sep 06, 2012 2:14 pm

You got my vote on that. :)

Thanks for posting.
maturmel
 
Posts: 24
Joined: Tue Jan 25, 2011 9:16 pm


Return to SQL Source Control 3

Who is online

Users browsing this forum: No registered users and 1 guest