Command Line: Sync to TFS (Not Syncroniznig)

Compares and synchronizes SQL Server databases, backups and scripts.

Moderators: JonathanWatts, Chris Auckland, David Atkinson, eddie davis, Anu Deshpande, Michelle Taylor, alice.easey, james.billings, chengvoon.tong

Command Line: Sync to TFS (Not Syncroniznig)

Postby hagenl » Tue Oct 01, 2013 11:45 pm

I can successfully compare a SQL Database with Source Control (TFS), however when I add the /Synchronize command, the differences do not get checked into Source Control.

It looks like the export starts (migration folder gets created and the differentials are printed as Verbose entries re: Command Line). Once the differentials are written to the log, the process just stops & TFS does not reflect any of the changes.

I have put what I believe to be the relevant parts of the Log run with Verbose enabled. If it makes a difference, the deployment where it is currently failing is two schema and one stored procedure (all updates to existing objects).

Code: Select all
15:30:16.043|Verbose|Command Line        |1  |Argument /synchronize has value 'True'
...
15:30:17.816|Trace  |Source Control Link |1  |SQL Source control link successfully created
...
__Info/Traces re: Comparison__
...
15:31:03.364|Info   |SQL Compare Engine  |27 |Comparison Finish.
15:31:03.365|Trace  |Source Control Link |27 |SQL Source control link successfully created
15:31:03.673|Info   |Source Control Link |27 |Exporting migrations folder to C:\\Users\\<user>\\AppData\\Local\\Temp\\Red Gate\\1f735c1c-979f-4340-b26f-670a53a8d7c3

hagenl
 
Posts: 6
Joined: Tue Sep 24, 2013 7:04 pm
Location: United States

Postby andy.campbell.smith » Fri Oct 04, 2013 5:55 pm

The /Synchronize switch isn't supposed to work deploying to source control, sorry!

Probably the best thing to do would be to check out the head revision, deploy to the checked-out script folder, and then commit that using your TFS client. Hope that makes sense!
Andy Campbell Smith

Red Gate Technical Support Engineer
andy.campbell.smith
 
Posts: 173
Joined: Thu Oct 20, 2011 11:19 am
Location: Red Gate Software

Postby hagenl » Fri Oct 04, 2013 6:09 pm

Oh no! We can still get our changes into TFS via SQL Source Control, so we can make it work.

Was really hoping to monitor & check into test using the command line - at least I'm still able to see the potential changes. Would be used for purposes of integrating into our mechanism for version control on a wide array of file types.

Any chance it is something being considered for a future release?

Thanks very much for your help!

Edit: I see what you're suggesting now would still give us what we need (I think) - will try to implement that. Thanks again
hagenl
 
Posts: 6
Joined: Tue Sep 24, 2013 7:04 pm
Location: United States

Postby hagenl » Fri Oct 04, 2013 11:23 pm

A couple challenges with that approach:

/MakeScripts Option
1) Doesn't apply the filter I'm sending to the Command Line
2) Must be used with a blank scripts folder

/Scripts2 Option
1) "Error: Deployment to scripts folders is not supported by VersionedWork." - I assume this is caused by SQL Source Control having a connection to TFS.

It might still be possible to use /MakeScripts but leverage another script to filter out unwanted files, based on the business rules we need and then check only the remaining files into TFS.

Open to other options, if you have any suggestions.[/u]
hagenl
 
Posts: 6
Joined: Tue Sep 24, 2013 7:04 pm
Location: United States

Postby andy.campbell.smith » Mon Oct 07, 2013 3:25 pm

Hmm - /Scripts2 ought to work, as far as I know. I can only find a few people who have hit that error before, and it doesn't seem like we ever figured out what caused it - one guy reported that it went away after a reboot, and another only ran into it after he'd been using SQL Changeset, which was the ancestor of SQL Source Control, and I assume that doesn't apply to you.

Can you try rebooting, on the off-chance that that might help? Sorry I can't be more specific!
Andy Campbell Smith

Red Gate Technical Support Engineer
andy.campbell.smith
 
Posts: 173
Joined: Thu Oct 20, 2011 11:19 am
Location: Red Gate Software

Postby hagenl » Tue Oct 08, 2013 4:48 pm

Restarting didn't solve the problem. Perhaps it is related to scripting out to a network drive? I will try locally at some point today to see if that resolves the problem.
hagenl
 
Posts: 6
Joined: Tue Sep 24, 2013 7:04 pm
Location: United States

Postby andy.campbell.smith » Fri Oct 11, 2013 3:21 pm

I've had a chat with the developers - this definitely should work, so we think it's a bug somewhere in our code. We're working on resolving that - I'll update you as soon as we've got somewhere, but do let me know if you can make any progress yourself. Sorry for the inconvenience!
Andy Campbell Smith

Red Gate Technical Support Engineer
andy.campbell.smith
 
Posts: 173
Joined: Thu Oct 20, 2011 11:19 am
Location: Red Gate Software

Postby andy.campbell.smith » Mon Oct 21, 2013 3:25 pm

Just following up on this - did you ever get the deployment to work?
Andy Campbell Smith

Red Gate Technical Support Engineer
andy.campbell.smith
 
Posts: 173
Joined: Thu Oct 20, 2011 11:19 am
Location: Red Gate Software

Update scripts folder works when SOURCE is scripts folder

Postby mattkarp » Mon Mar 10, 2014 7:05 pm

I got the same, "Error: Deployment to scripts folders is not supported by VersionedWork.", error when trying to update a scripts folder using "Direct from source control" as my Source. If you just get latest version of this folder to pull it down locally and then switch your source to "Scripts folder" this error went away and I was able to update my Target Scripts folder no problem.
mattkarp
 
Posts: 6
Joined: Mon Nov 01, 2010 7:03 pm

Postby jessiebruck11 » Sat Mar 22, 2014 8:44 pm

I had the same problem with /Scripts2, but for it worked for me after a reboot. Sorry I can't be more help.
jessiebruck11
 
Posts: 1
Joined: Sat Mar 22, 2014 8:38 pm


Return to SQL Compare 10

Who is online

Users browsing this forum: No registered users and 1 guest