I have new files added on TFS and some other checked out but on my older workspace. Now my machine is changed and I want to have those files on my new workspace.
Is there any way to have these changes replicated/imported to my new workspace?
You have to check in the changes or create a shelveset on your old workstation and take a get latest on your new computer.
http://msdn.microsoft.com/en-us/library/ms181403(v=vs.80).aspx
If you still have access to your old machine, you can either check in the changes or put them on a Shelveset (if you don't want to check them in for everyone to see). Then on your new machine either do a Get Latest Version (when you had checked the code in) or Unshelve the changes to your new machine.
If you don't have access to your old machine, then these changes are not available. TFS doesn't get the changes version of your files until you either check in or shelve. You'll have to consider them lost and unrecoverable.
If you have access to the old machine, but the old machine can no longer access TFS, copy the old workspace to the new machine and then use the Compare folder option to merge your changes into your new workspace.
To prevent accidentally losing your changes you can install an extension which automatically shelves your changes.
Related
I got a new computer and I have to move my TFS workspace. I found confusing info online, is this the correct approach?
Add TF server in VS of new machine
Copy folders from old machine to new machine (I have some files with pending changes)
Update TF workspace in new machine using the command:
tf workspaces /updateComputerName:oldCompName /s:"serverURL"
In VS (new machine), map projects. Is this required?
If you copied the entire workspace folders, then the map projects is not required, otherwise you have to map the projects (manage the workspace and map to the copied folder).
For example, if the original workspace is mapped to D:\Ad-workspace\2017\SCRUM-TFVC, then you have to copy the folders to the same path in the new machine.
Actually, you don't need to copy the workspace, just create a shelveset for the pending changes in the old machine, then connect to TFS from the new machine and map to a new workspace, then find the shelvset and unshelve, all the pending changes will be back to your new workspace.
TFS workspaces are identified by the owner, the computer name and the workspace name. If your new computer has a new name, you need to update your existing TFS workspaces to reflect that change.
Your process is correctly and the last step is required. After establish the mapping, you may get a promote message:
Newly mapped items will not be download, until you execute a get...
You could perform a get. Then copy your back-up files/folders which copied from main branch to the new dev branch. Windows system will judge to replace files and add new files.(It may take some time) After this, TFS system will auto detect the changes in local and will list them as new pending changes.
Everything get back to the same as you work in old machine.
I started using TFS since VS2010. By that time I already created my own TFS server (myname.visualstudio.com). My problem is that I created a new project on the my TFS website (the one with the dashboards). Then when I go to VS2017, and connect to that new project, it asks me to map and get it as expected. Instead of just clicking "Map & Get" button, I instead clicked advanced so that I can configure everything.
On the workspace configuration dialog, I noticed that VS names it as "MYPCBLABLA_1". If I try to remove the "_1", VS says that "the workspace blablabla already exists on computer blablabla", and does not let me use my existing workspace name.
Why does it do so? Can I not use only 1 workspace? From what I understand of workspaces, it is the container of my projects, so different workspace, different set of projects. But what are they really?
Additional info:
I don't know if this helps but on the past, I used to format my PC many times, I'm not sure if that affects the mappings or workspace names when I use VS after reformatting.
Workspaces are maybe the least well-understood feature in TFVC. And you are right in saying they're a way to isolate different sets of files from a TFVC repository.
A lot of people configure a new workspace for a specific project or set of solutions, but let's look at some of the ways workspaces can be used in detail:
Hotfixes: you may need to create a hotfix for something happening now, but you have pending changes in your existing workspace. Instead of shelving these changes, performing a "Get Specific version" on the bugged version, you can also create a new workspace in which to solve this particular problem. After completing the fix you can then continue working with the other workspace without needing to do anything.
Experiments: you may want to do some major refactoring, restructure source control or some other highly impactful operation. Doing this in a new (temporary) workspace helps you prevent messing up your normal work area.
Reviewing other peoples changes: When performing a review on another person's changes, you may want to have a local copy so you can run, annotate and play with the other person's code. Instead of taking these changes into your own workspace, you can easily bring these into a temporary workspace, which you can safely delete afterwards.
Performing a merge, while you are working on other changes: It may be the case that you're working on a new feature an already have some changes merged back to another branch when a release needs to be shipped. In order to prepare this release, without picking up changes or overwriting work in progress in your current workspace, it's often easier to perform these kinds of release activities in a temporary workspace, that way you know that the work is always done on the exact version in source control.
Preventing accidental changes to important branches: By putting your production branch in a separate workspace, you can't accidentally combine changes from say Development and Main into a single check-in. Since Visual Studio often auto-selects all pending changes in the workspace, this may cause unintended changes to your master/main branch. I've written a Check-in policy to prevent these issues, but having separate workspaces is a much safer solution.
Working with multiple developers on the same workstation/server: in some organisations, developers use a remote desktop to a central beefy server to do changes. To ensure each developer has his own set of files, each developer gets his/her own workspace. An alternative is to make the workspace public, which allows multiple developers to use the same workspace folder. But this often leads to all kinds of unexpected issues.
Browsing an old version of the code: if you need to review/compare an older version to a new one, you can often get away with the folder diff view in Visual Studio, but if you need to do more thorough comparisons, you may want to have 2 copies of the same folder in your TFVC repo. Creating two workspaces will allow you to have two different versions of the same folder on your local disk.
Prepare a special version for merges or labels: You can merge and label the workspace version of a set of files. You can create a workspace and then use Get Specific Version to fetch specific versions of specific files, these can all come from different changeset versions. Once you're satisfied, you can perform the label or merge or branch action to store this specific workspace version configuration on the server.
As you can see, Workspaces allow you to do parallel development on one machine, isolate changes etc.
Be creative
As you can see, workspaces are a very powerful concept. Usable for a lot of operations. But you need to understand the concept thoroughly. Many developers don't understand exactly what workspaces are and how they work, they're missing out of some of the most powerful concepts of TFVC.
Consolidating and cleaning up
In your case you now have two workspaces. In order to consolidate these (if you want to), you can unmap the folders from your _1 folder and then map these same folders in your original workspace. You can also delete the _1 workspace from the TFS Server and then update the mappings of the original workspace.
Remember that workspaces are stored on your local machine, but that the TFS server also has a registry of who mapped which TFVC folders to which workstations. So simply deleting files from your local disk is not sufficient. You need to save these changes to the TFS server (this happens automatically after performing a get operation after changing the mappings).
To check which workspaces are registered to your workstation on the TFS server, use:
tf vc workspaces /computer:YOURWORKSTATIONNAME
Then delete old workspaces with
// DELETE the local workspace
tf vc workspace /delete:WORKSPACENAME
// DELETE the workspace registration on the TFS server
tf vc workspaces /remove:WORKSPACENAME
To prevent the creation of a new workspace by VS, I:
Create a local folder to which I’ll map the content of the remote repository;
In VS, connect to the remote repository;
In VS, open Source Control Explorer and navigate to the content I need; VS will show a “not mapped message”.
Click on that message and map locally.
This guarantees that no other workspace will be created, and the current one will be used.
As usual I extensively searched for a solution before asking here, I'm really stuck.
I'm currently working on a customer TFS server and I have no administration rights whatsoever. Me and a colleague were using the same user account, which I know is a bad practice but again I had no choice here.
Today we found out that the account is expired and the customer is saying that it will not be reactivated. Instead they gave us a new account.
The problem is that in our local workspaces we had some uncommited changes. I'm trying to find a way to reassing the local workspace to a different user but every path I tried leads to a dead end.
One thing I tried was to access the current workspace and set it to "Public" so another user can work on it, but I can't access the current workspace as I am offline and the user is expired.
If I change TFS credentials and try to Get Latest Version or anything else I don't see the old workspace but only the workspace(s) of the new user, which has no "Use" access to my local workspace.
I also read that a manual merge of the changes (using KDiff or Winmerge) is discouraged as TFS doesn't see edits done outside VS so it wouldn't know the files have been modified. I personally noted this behaviour when I tried to change some nodes in .csproj files with Notepad++ and TFS didn't give me the file in the pending changes.
Anyone knows the proper way to work with a new user without losing the local changes?
Thanks.
1)Create a branch for the latest change set from the server
2) Check out the files to your workspace
3) Overwrite the files in worspace
4) Now the branch contains your changes
5) Merge the branch which contains your chnages with the latest.
You have three options:
If you are using TFS 2012+ and VS 2012+ you can create a new workspace as the new user and make it a 'local' workspace rather than a server workspace. Then just drop the changes in a VS will detect them.
If you are using an old version of TFS and/or VS you can use the 'go online' option (2010 only)
If you are using a really old version you may need to checkout the entire workspace before dropping the changes back in.
Update: In order to achieve a merge of the changes you could create a branch from the last/latest changeset that you 'got' from the server. Then just overwrite you files... You now have a branch with just your changes and you can then user the merge tool to stitch it back together.
note: Also note that you should check in code frequently (at least daily) to avoid this issue in the first place.
Another user on a different machine checked out files and was working on them until her computer crashed, keeping those files checked out. Is there a way to check in that work?
Some files in one repo she's made some changes to since her computer was reimaged. She was able to save them, but I am not sure if they will be permanently changed. If the old files are checked in, will it affect the changes that she's made in the past couple days? Is there a way to accept the most current changes?
I've used the workspace sidekick from Attrice, but not sure if that is on the right path.
Files that are checked out should be viewed as a reservation. If the files exist in the form that can be checked in either:
Recreate the working folder and recreate the workspace and copy the files to the correct subfolders and check in
preferred approach cancel the check-in, create a new workspace, get latest and merge the copies of the files into the new workspace and check-in.
the undo from the other workspace can be accomplished with the following tf command.
tf undo /workspace:OtherUserWorkspace;OtherUser $/Project/ItemName.cs /s:http://yourtfsserver:8080
I got new working machine and because our TFS server is located very far from jobsites I want to avoid downloading all source codes again (several GBs) so want to move my old workspace to new one. I have copied all projects via LAN and Working folders list in Workspaces is empty in VS on new machine.
So how to move all items from old workspace to new one without adding them manually and downloading all the data again?
It's super easy to migrate your workspaces from an old machine, given your exact scenario. See this other thread on Stackoverflow:
Import Visual Studio TFS workspaces
Shelve everything in your workspace and unshelve it to the new computer. When you create the shelfset, make sure that "Preserve pending changes locally" is not checked.
This will, effectively move the workspace from one computer to another.
** Update based on question being updated **
I don't think there's an easy way for you to do what you are wanting to do within a workspace. Instead, you should be looking at the TFS Proxy. When you implement the proxy, it sits between your workstation and the TFS repository, and helps proxy gets, check-outs, and check-ins to help speed up your interaction with TFS.