I'm using tfpt tool for moving a shelveset from one branch to another. I've read some stackoverflow questions about it but neither seems to fit to my problem. I'm running the command like this:
tfpt unshelve "my shelveset name" /migrate /source:source_brach /target:target_branch
When I'm doing this I'm getting an error like this example:
The change to filen_name_with_path cannot be unshelved because the
server path is not mapped in the local workspace
Make sure your workspace mapping includes both branches. Do a get latest on both branches first to test this is setup right.
Make sure that
One or more of your workspace mappings include both branches (they do not have to be in the same workspace);
The location from where you launch the command is in your target workspace.
All you have to do is go to your target branch mapped local folder using cmd and run the command from there. It should work
Related
I downloaded Team Server Power Tools (TFPT) to be able to take a shelveset that was created on one branch and unshelve it on another. But for some reason, TFPT insists on asking for the target server path, which I find a bit ridiculous since it should be visible to TFPT.
A quick look around, it appears that there is an API that will state the server path, but I would rather have this available through scripting. Is there a way to get the server path through scripting?
If you have a shelveset called MyChanges on the Main branch in a Team Project called MyProject and you want to unshelve it to the Dev branch instead then the tfpt command would be:
tfpt.exe unshelve /migrate /source:"$/MyProject/Main" /target:"$/MyProject/Dev" "MyChanges"
I'm trying to use tfpt to migrate a shelveset from a source branch into a target branch, but it doesn't appear to do anything...not that I'd expect much more...but any chance anyone knows what's wrong? I'm following the instructions correctly I think...
I've got:
tfpt unshelve "DbMigrations" /migrate /source:$/TeamProject/Main /target:$/TeamProject/Releases/7.20
What happens after you run the command? You need to have a few things set up before migrating:
A workspace that encompasses both the source and target branches.
You need to run the command in a folder within the source.
Once you run the command you should be asked to merge the changes from the original shelfset into the destination branch and resolve any conflicts, which finally pends a changeset on your client. Nothing is touched on the server until you check that changeset into TFS itself.
I experienced the same problem and I could not get it to work by specifying the shelveset name. However, I discovered that if you remove the name of the shelveset altogether, TFS will pop up a window with a selection list of available shelvesets to choose from. Select the desired shelveset and perform all other merge operations as per normal.
Example: c:[mapped workspace target path] > tfpt unshelve /migrate /source:"$/Sourcepath" /target:"$/targetpath"
You need to use the branch paths on the TFS server, not your local machine. To find the paths, go to source control explorer in visual studio, right click the branch, advanced > properties, and you want the branch name, not the local path. If the path has spaces, wrap it in double quotes.
I have to migrate the shelveset created in one branch say "development" to another say "release".
so that I can directly merge the shelveset then to release which was created for development branch.
the command I have used is:
tfpt unshelve "shelveset name" /migrate /source:"$...development" /target:"$...Release"
it is showing this error:
unable to determine the workspace
Your location from where you launch the command must be from within your workspace.
E.g. c:\workspaces\project\development if that's where your source is located.
I guess you question is: How can I get the job done without this error occurring?.
In that case, make sure both branches are mapped to your local system and a latest version of your source code in you did a get-latest-version.
That should prevent the error from happening, because the paths then both contain information about the workspace used for the mapping.
I ran into the same issue today.
After checking the items below I got it working:
Have only one Powertools installed.
Run the command from a Developer Command Prompt
Run the command from the folder that is mapped to your target workspace.
I had to uninstall v. 2010 so only v. 2012 remained. The version numbers doesn't seem to reference your TFS version.
To check if you are at the correct folder, you can run tf workspace.
In the window that pops up find the workspace that you want to target and check in column Local Folder. Make sure you are in that folder.
I spent good amount of time to get this done and I had few issues to overcome and one of these in fact was
unable to determine the workspace
This particular issue was solved by running the command from source branch root folder. This is contrary to some answers here and on SO in general where they say to use "target" branch - no, use "source":
cd [your !!source!! branch root]
tfpt unshelve /migrate /source:"$/MyCollection/Development/Maint1.1" /target:"$/MyCollection/Development/Maint1.2" "myShelveset;UserName"
Second issue appeared after this. Seem that it couldn't connect to TFS server. what I realized, I have multiple VS installed and connected to different TFS servers. I was using VS12 and I had workspace and server connection. But I didn't realize that same connection needs to be replicated in VS13 for TFPT2013 to work. It connects to same server and workspace.
I also tried doing it using TFPT2015 but I installed it and it didn't install TFPT.exe hence it was useless. So I tried from TFPT2013 to TFS2015 and it worked for this particular command. I wonder, why not, if VS12/13 works fine against TFS2015?
To summarize
Use CMD or DevCMD - doesn't matter
run from source branch root folder
verify Team Explorer Server connection
TF Power Tools 2013 work against TFS v15, at least migrate option works
My first answer explains how to have this done properly using TFPT. In this answer, I want to explain how to do it without TFPT.
Every developer should have multiple workspaces. Because we work on multiple issues simultaneously and we don't want to mix it up. so, you work on one issue in WS1 and another issue in WS2. So, if you unshelve your shelveset in a different workspace, this will do that as well. Because your shelveset can't point to 2 different locations in the same workspace. But in different workspace it will unshelve to a location mapped in that workspace.
I ran into the same problem as Boris Callens. I had installed the TF Power Tools for VS2012 and VS2013. When runing the tfpt.exe command in command promt I always had the error message "unable to determine the workspace". This is because I was using the VS 2012 power tools with TFS 2013. So I had to change the Path to the Power Tools in the System Environment Variable "TFSPowerToolDir" to point to the Power Tools for VS2013.
You can find the version number running: tfpt.exe /?
TF Power Tools version
I type this command: tf workspaces into a command line and it tells me there are no workspaces on the machine. I then try the same command on the server, nothing. So I go into Visual Studio 2010 and create a new workspace and try to map the TFS path to my local path. I then get an error that the mapping already exists in another workspace. But I cannot find that workspace on my local or on the tfs server. Any ideas?
You can run tf workspaces /remove:* to clear out your local cache of workspaces. See this link for more details.
I know this is an old question, but I just came across this issue on a Linux machine running TEE (Team Explorer Everywhere). Running "tf workspaces -remove:*" didn't work, because it said there were no workspaces in the cache.
The user was trying to create a new workspace, which worked, but when he tried to map folders, it told him it didn't exist.
When he ran "tf workspaces" on the machine and when I looked in TFS Sidekicks on the server itself, it didn't show any workspaces for him on the Linux box.
If he tried to create the workspace again, it told him that it already existed, but every time he tried to map, he was told it didn't.
We could see the workspace from the tf command line if I did "tf workspaces /owner:", and it required me to run "tf workspace /delete ;" from the command line to get rid of it.
Once we did that, he was able to create it again and everything worked properly.
No idea why that happened, but figured I'd post my answer here just in case someone else comes across a similar issue in the future.
We have been using CC.NET as our CI server for a month or so now, which has worked ok with TFS. In the config we were able to specify the TFS server, username, password, project and workspace which is all good.
Now we are moving over to TeamCity mainly because it just seams more solid and is much nicer to use. The problem is getting it work with TFS.
For the purpose of this, both the workspace and machine name are "BuildMachine", username is "BuildUser" TFS project is "$/Project/Dev/Website"
I seam to have set it up correctly, I think, as when testing the connection it is successful. When I run a build I get a TFS error: "RunBuildException when running build stage UpdateSourcesFromServer."
It goes on to say: "No matched workspaces were found. Will recreate workspace and perofming clean checkout."
It then tries to create a new workspace something like this: TeamCity-S-sqa9qe2aulx22gz4rzkogl5kr/BuildUser
It tries to set up some mappings and then fails because: "The working folder C:\ is already in use by the workspace BuildMachine;BuildUser on computer BuildMachine".
This seams ok as this is the workspace that CC.net was using, and c:\project\dev\website is the path to the project. The problem is, why didn't TeamCity pick this up and use this workspace? Why does it try to create its own new one? Any idea how I can fix this?
Thanks
I seem to have fixed this by simply changing the path for the BuildMachine workspace to c:\BuildMachineWorkspace\ instead of just c:\.
I guess this means that the whole of c:\ is no longer a workspace therefore other workspaces can be created on c:\.