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.
Related
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.
Oddly, source control seems to be holding onto files & projects even though I have deleted the artifacts from the Visual Studio Solution (itself). The GetLatest brings down the correct files (even when I delete the underlying artifacts from my workspace by hand). I have never seen this behavior in other servers...in fact...not even my PERSONAL Visual Studio Online behaves this way.
Now...to delete files...I have to delete things twice: once in the solution & once in TFS.
MY QUESTIONS:
Why is TFS holding onto the files in Source Control?
Is this a setting?
How do we fix this?
This is an internal TFS server & I am not the administrator. They are "new" so I am sure I will have to explain the issue at-length.
FOR EXAMPLE:
It's a normal phenomenon. Team Foundation Server uses your workspace to keep track of what files you have downloaded and what version you have of them. The reason it does this is so that it can maintain your files without a costly sync step. With TFS, when you say "Get latest", you only get the latest version of files that have changed since you last got them.
If you delete a file on the server and check that delete in, then when somebody does a "Get Latest", the file is deleted on their local system as well. It's for keeping the local file system in sync with the servers.
If you want to just delete the folder and files locally, there are two way to achieve it, more detail info please refer the answers in below question:Delete Local Folder in TFS
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.
I currently have a TFS 2010 Server running on SERVER-1. On my client (MY-CLIENT) I have VS2010 running and have a workspace associating SERVER-1 with \MY-CLIENT\Development. All is good.
I was playing around with setting up a different instance of TFS on SERVER-2. On my client, I deleted the original SERVER-1 workspace and created a new workspace associating SERVER-2 with \MY-CLIENT\Development. All is good.
Having finished my experiments with TFS on SERVER-2, I re-imaged the machine (deleting the TFS Server on SERVER-2).
I then went back to my client machine, reconnected to TFS on SERVER-1 and attempted to remap source control to my Development folder. However, am now receiving the error "The path \MY-CLIENT\Development is already mapped in workspace MY-CLIENT;SERVER-2\Steve." Now I have a problem.
So, I gather from this that I should have first deleted the SERVER-2 workspace BEFORE re-imaging the machine. Unfortunately, I did not do that.
Poking around in some forums, I realize that I can use a command line tool to perhaps delete it:
tf workspace /delete MY-CLIENT;SERVER-2\Steve
However, when I run this, I get a message indicating that "Team Foundation services are not available from server http://SERVER-2:8080/tfs/development."
So the question, then, is how do I force deletion of the SERVER-2 workspace on my client so that I can re-create my old SERVER-1 workspace?
The working folder mappings for all the local workspaces is stored in the version control cache file. This allows you to bootstrap TFS clients, allowing them to locate the server information for a given local folder. In addition, it will provide the information for this test you're seeing, that prevents a local folder from being mapped to two different servers.
In order to clean this up (without trying to connect to the server), you can use the tf workspaces command (note the pluralization - the workspaces command operates on the list of workspaces, the workspace command operates on a workspace and generally requires connectivity to the server that workspace is located on.
To delete all workspaces for your deleted project collection, you can do:
tf workspaces /remove:* /collection:http://server-2:8080/tfs/DefaultCollection
(Obviously replacing the project collection URI with the URI for your deleted server.)
I had exactly the same issue: After moving TFS server to another machine, I couldn't map to a local folder in VS2012 on the old machine because it was still associated with an old Workspace that TFS denied all existence of. After many hours (and days) searching Google and trying different things, none of which worked (including all the "tf" commands, deleting the local cache etc), this is how I eventually solved it:
Edit the actual TFS collection database on the TFS server using SQL Management Studio Express (e.g. "Tfs_DefaultCollection")
Look for the "dbo.tbl_Workspace" table and edit it
You should see your "ghost" workspace(s) in here
Delete the rows
All is right in the world
The workspaceowner parameter on the delete command is optional. Can you issue the delete without that parameter, or will that damage another MY-CLIENT workspace?
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.