Aside: Since I'm using Powershell to run all this, why do I use the TF.cmd application instead of the Cmdlets? Simplicity. The Cmdlets appear to need the FULL version of a TFS client installed, plus you have to grab and install the cmdlets... and there are bugs if you don't use the right (x32 vs x64) version of the cmdlets with the right version of powershell. So I built it around the TF CLI (Command-Line Interface). The original post was for 2008, the new one (plus script below) are for 2013.
Upgrading from 2008 to 2013 blows, since the config and cache can be screwed up.
What I had to do was completely drop the workfold and the workspace (PROTIP: first, list your workfold and workspaces and SAVE THOSE DETAILS), delete the entirety of the cache folder, delete everything from my EN_Workspace folder on disk, then rebuild from scratch.
One other oddity: before, from the root of my installation (c:\tfs_cli) I could run the script, and it could properly list the folders underneath it. That appears to have changed for some reason; my Powershell script now CDs into the subfolder before it proceeds. Not a major change... but took several hours to diagnose, since I was also fighting with other issues on the setup. Caveat Emptor and all that.
Also for the TFS newbies: the default path you use for a LOT of things is:
Steps to get going:
- Install Java. Got it from Oracle, which doesn't appear to have the same cruftware that Sun's does. Version 7-something
- Grab Team Foundation Everywhere 2013. Reading the docs, it works for TFS 2010, 2012, 2013, and Online. http://www.microsoft.com/en-us/download/details.aspx?id=40785
- Unzip into one massive folder (I called mine "c:\TFS_CLI\APP_2013"), then try running (since I'm on Server 2012, in Powershell):
- it works - success! Sorta.
- Found this page which seems to make the below setup easier:
- For the rest of this, I'm doing it as the Service account that SQL Server is running under on the box that will run the job. Oddly enough, it wasn't set that way when I built it on 2008, but it continued to work even though my password changed. Note that nowhere in here do you actually put in a password.
- Type ".\tf eula", then accept ("y").
- muddle through the web site (tfsservername:8080/tfs) and add the SQL Service account as an admin to the branch I'm using (YourENProject).
- Using the MS page above:
- .\tf workspace -new TF_Workspace -collection:http://mytfservername:8080/tfs/DefaultCollection
- the collection URL is pretty standard - it should work in 2010,2012,2013.
- .\tf workfold -map $/YourENProject -workspace:TF_Workspace c:\TFS_CLI\EN_Workspace
- This line has several names. Let's break them out.
- $/YourENProject is the "Branch" in TFS. Call it something like $/ProductionEN or something like that. I created the branch using SSDT before I did any of this, but you can create one using the TF.exe
- TF_Workspace is the workspace you created in the step above.
- c:\TFS_CLI\EN_Workspace - the physical folder on your EN server (NOT the TFS server). I named them differently to make it more obvious what each part of the command is doing.
- now try and check something in.
- Get to the workspace
- cd c:\TFS_CLI\EN_Workspace
- new-item test.txt -type file
- &cmd /c "c:\tfs_cli\app_2013\tf add test.txt"
- &cmd /c "c:\tfs_cli\app_2013\tf checkin /author:memyselfandi"
- I use that weird syntax to catch errors and return as text into Powershell, so it can properly eat and pass on errors as necessary, as opposed to having PS choke on it.
- Pull and update something: this is where I had massive problems. (use script)
- Finally verify it worked (I used my "real" TFS client on my desktop).