Comments
12 comments
-
Hi - I'm afraid SQL Source Control doesn't officially support TFS 2013 yet, but we're hoping to have something out soon that does. I'll let you know as soon as I've got some idea on when that would be - in the meantime we'd suggest using the Working Folder option and committing manually. Sorry for the inconvenience! -
andy.campbell.smith wrote:Hi - I'm afraid SQL Source Control doesn't officially support TFS 2013 yet, but we're hoping to have something out soon that does. I'll let you know as soon as I've got some idea on when that would be - in the meantime we'd suggest using the Working Folder option and committing manually. Sorry for the inconvenience!
The working folder option in TFS or SSC? Could you detail a little how this would work? -
In SQL Source Control, when you link a database you're presented with a number of options for your source control system. If you pick "Working Folder," SQL Source Control will just commit changes to a directory on your hard drive, which you can then manually commit to TFS.
There's an article about working folders in SQL Source Control on our documentation site, but it doesn't say much else: http://documentation.red-gate.com/displ ... ng+folders
Does that make sense? -
One of our engineers is reporting that SQL Source Control seems to be working OK with TFS 2013 on his test VM - that'll be using the TFS 2012 client DLLs, which you can get by installing the 2012 client tools available here:
http://www.microsoft.com/en-gb/download ... x?id=30656
We haven't tested this, so I can't promise that it'll work, but I can say that we're not aware of anything that's broken in it yet. If anything does seem not to work, the first thing that we'll suggest is using a working folder to commit instead. -
Andy - Thanks for the follow-up.
We'd be using the TFS 2013 client DLLs (VS 2013), although the 2012 DLLs would still be there since we'd just do an additional VS 2013 install on the same clients (so both client DLLs would be installed).
Re: Use working folders - any differences with how the sql files are generated etc. by SSC when using working folders vs. the TFS integrated config? Essentially, I'm concerned with switching from TFS integration w/ 2012 to Working Folders for 2013 and then trying to switch back to TFS integration once it's supported for TFS 2013. -
Using a working folder will generate exactly the same scripts that it would for TFS or any other source control system, so there shouldn't be any problem using a working folder for now and then switching back to the integrated TFS support once we're ready with that.
-
Has there been any update on this? We recently migrated to TFS2013 and I just realized that I couldn't use SQL Source Control.
-
We're working on testing this right now - it's difficult to tell how long it'll take at this point before we're happy to release, but we're hoping it'll be very soon. Sorry about the inconvenience!
-
How's testing going? Any further news on this?andy.campbell.smith wrote:We're working on testing this right now - it's difficult to tell how long it'll take at this point before we're happy to release, but we're hoping it'll be very soon. Sorry about the inconvenience! -
Still waiting for TFS2013 support. Any word???? It's only deep into 2014 now. :-)
-
We're more or less ready to go with TFS 2013 functionality - we're expecting the next SQL Source Control release to include it, unless something goes wrong. That should be very soon - I'll update this thread when that goes out.
-
SQL Source Control 3.6.0.3 has been released today, with support for TFS 2013: http://documentation.red-gate.com/displ ... ease+notes
It's only available to users that have turned on frequent updates - you can find out how to turn on frequent updates here: http://documentation.red-gate.com/displ ... nt+updates
Add comment
Please sign in to leave a comment.
Thanks!