Command Line: Sync to TFS (Not Syncroniznig)

hagenlhagenl Posts: 8
edited March 22, 2014 3:44PM in SQL Compare Previous Versions
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).
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

Comments

  • 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
  • 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
  • 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]
  • 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
  • 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.
  • 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
  • Just following up on this - did you ever get the deployment to work?
    Andy Campbell Smith

    Red Gate Technical Support Engineer
  • 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.
  • I had the same problem with /Scripts2, but for it worked for me after a reboot. Sorry I can't be more help.
Sign In or Register to comment.