We are in the process of migrating/upgrading our TFS2010 to TFS2013, new infrastructure.
We are following the step by step upgrade guide.
Regarding workspaces, do the developers need to remove all the local mapping to the old TFS instance before the upgrade? If Yes, we can ask them to remove.
However is there any way to find out whether the developers have removed all their local workspaces from TFSadmin point of view rather than asking the developers to say whether they have removed or not?
Best Regards
However is there any way to find out whether the developers have
removed all their local workspaces from TFSadmin point of view rather
than asking the developers to say whether they have removed or not?
Installing TFS Sidekicks will allow you to see what workspaces exist for a particular User / Machine, it will also allow you to delete workspaces and to remove file locks.
It is not required when doing an upgrade to have developers remove workspaces. After the upgrade Visual Studio will automatically match it all up correctly.
Note: Make sure that you only do this for production. If you are doing a trial migration you MUST change the server ID to prevent VS getting confused!
http://msdn.microsoft.com/en-us/library/vstudio/ee349259(v=vs.110).aspx
Related
I assumed this would be easy, but I'm not finding anything on it...
I have a project in TFS 2010, which needs to be moved to a new TFS 2015 server. Apparently the project cannot simply be moved normally because it's using a different project template which is not compatible and causes errors when trying to migrate (so I'm told - I don't have any more details on this).
I'm looking for a way to bring over the changesets, keeping history, to the new server. I assumed there was some kind of "dump" where you could export the TFS changesets, then import them into the new server into an empty project - but I'm not finding that option.
TFS Integration is deprecated and apparently doesn't work for TFS2015, with no alternative listed.
I'm open to other creative options like temporarily exporting to a different version control system - for example, I've looked at SVNBridge, but I can't even get that working, let alone figure out if it would help here.
Is there a way to migrate all changesets for a given project and keep history, without migrating the entire project?
There is no default way to migrate changesets in TFS, you would need 3rd party tool, like OpsHub (some features are not free), to migrate the most commonly requested data. Check: http://www.opshub.com/products/opshub-visual-studio-migration-utility/
Or you may consider doing a upgrade from TFS 2010 to TFS 2015, which is a full data transfer. To understand factors that affect your upgrade's compexity, check the requirements and review the upgrade process.
Learn if a dry run makes sense for you, and weigh the benefits and the costs to perform a pre-production upgrade.
When you're ready to upgrade, minimize downtime with the TfsPreUpgrade tool - especially for very large TFS collection databases (> 1 TB). Follow these steps for how to upgrade TFS.
We have upgraded our TFS from 2010 to 2013, and the same time moved the TFS and databases to new servers, with new names.
One of the very few annoying effects (Probably due to moving the TFS to a server with a new name) is that the build controller/agent from the old server is still visible in lists of available build controllers/agents, but is not visible in the admin gui for build configurations and therefore not possible to remove.
Does anyone have had the same experience and furthermore have a solution of how to remove the traces of old (and not used/wanted) build controllers/agents?
Kind regards,
J
Ok.
Sorry, I found the solution myself now after continue searching and yet again scanning through the microsofts documentation! :)
It's possible to disable and delete controllers and agents through the Manage Build Controllers in Visual Studio.
Also described here: http://msdn.microsoft.com/en-us/library/ee330987.aspx
Just make sure there is no builds in progress, but that's ofcourse also possible to handle through Manage Queues in Visual Studio.
I have installed and configured TFS 2010 on a Win 2008 server. I have tested the migration and everything seems o be working fine. I have one issue with the Domain move though.
I am trying to use TFSCONFIG IDENITIES /change command to map the Users in old domain to new domian, but unfortunately the new domain accounts have been added to the TFS group. Hence, I caanott use the Identities /change command.
I am still trying to figure out what needs to be done in order to sync up the accounts b/w two domains. What are my options in this situation? Can I just uninstall and re-install TFS 2010. Would that help me sync up the account names b/w two domains? Please advise
There is extensive guidance available on the different supported upgrade scenario's.
Probably the easiest way to do the upgrade is to install TFS2010 over the 2008 version and then do a domain migration. It looks like the issue you're facing is that you added the new account members, instead of migrated the old members to the new ones. I haven't been in that scenario before, you could try removing the new accounts and then migrating, or using the TFS integration tools to migrate all data for one user to another user.
If you still have a backup available, or if the TFS 2008 server is still there, I suggest re-doing the migration, however painful that may be, it will be the safest way to get everything to work again.
Finally there are the The TFS Integration Tools can be used to migrate from one TFS instance to another, they don't migrate everything, but will migrate the most important things.
I started work a lone developer last year and I found VSS is no longer a good option for source control so I decided to use TFS 2010 instead.
I have had to learn everything from a book - of which there are few.
I am currently creating a new build and in my workspaces I see a have 4. I want to delete one of them and rename another.
However I do not know what the consequences of doing this are. If I delete a workspace, will that remove the associated files under source control? How do I check which files these are? What happens if I change a status from active to cloaked?
As you can see, I am a beginner in all this.
Workspaces are only a mapping from SourceSontrol folders onto your local file system. Also workspace contains information about versions of the files you have locally, so when you hit 'Get Latest Version' only recent changes are sent from server to you, not the whole files. Information on what files are checked out is stored in workspace too, so if you have pending changes in the workspace and delete it then there'll be a bit of a challenge to check these changes in. Renaming of the workspace will not break anything as far as I know.
Article An introduction to TFS Workspaces may be interesting to you.
Like the others have said, the workspace only says what local files you have checked out, and the status, etc. Workspaces are pretty granulal (i.e. per user and per machine) so you could have mutliple workspaces with the same username in the same project. E.g. if you have a copy of Visual Studio at work and one at home, you could have different files checked out and you wouldn't run into any conflicts like you would have in VSS or something based on VSS Like like VSSConnect.
We've had a couple of people leave out project and have had to go in and remove their workspaces after the fact. This hasn't been a big deal in terms of any code losses but if you don't have access to the machine anymore you will have to use the TFS tools.
Try TFS Sidekicks, it provides a nice GUI to manage all the nitty-gritty back-end stuff in TFS
Let's say I have my TFS team project setup the way I want it, and all the code between my machine and the team project is in sync (i.e. if I do a get latest it says everything is up to date).
What I would like to do is test whether or not I can pull the project back down to my local machine from TFS source control have everything work properly. By work properly, I mean I'm able to build all the projects, run the web sites, etc.
I thought what I could do is just blow away the code on my local machine and then do a get latest. But TFS seems to think that my local machine and TFS are still in sync (this is a bit different from the way Visual Source Safe worked).
In a nutshell, I'm just trying to test whether or not if another developer were to pull this team project down to their machine, that I know the project is setup correctly with all the necessary dependencies, etc. such that the other developer could build and run the project. But since I only have one machine to test this with currently, I need to do this test on the same machine.
The only way I've found to do it is to use "Get specific version" and force it to overwrite existing files, but it seems like if I delete the stuff off my hard drive, it should know when I do a get latest that "hey, the files aren't there anymore, I need to pull them down".
Any ideas on how I can do this? Thanks.
Not withstanding the answer above highlighting the merits of having an automated build process and continuous integration...
The easiest way to validate what you've checked-in is to create a new workspace with the same folder mappings, albeit to a different location on your hard-drive. You can then 'Get Latest' into this new workspace and confirm that everything builds locally, this should prove that:
The correct versions of existing files are in source control
All the required files have actually been added to source control
Alternatively if you'd rather not check-in your changes until you've validated your pending changes, then your best bet is to 'Shelve' all your changes (ticking the box to undo your pending changes), and then 'Unshelve' that shelveset into a new Workspace and do your testing against that instance of the codebase... or even ask a colleague to pull down your shelveset and do the validation (typically this called a 'Buddy Build').
TFS is a little different that VSS in that local workspaces are maintained so that every file doesn't have to be compared with every GET. In addition to removing the code from your development machine, you should also delete your local workspace. Check out "Working with Version Control Workspaces" on MSDN:
http://msdn.microsoft.com/en-us/library/ms181383.aspx
Really, though, the best way to make sure that your code can be pulled down and built easily is to create an automated build in TFS for continuous integration. That way you know immediately if you have done something that would make the solution un-buildable.
Check out the overviews of Team Foundation Build on MSDN:
http://msdn.microsoft.com/en-us/library/ms181710.aspx
The answers above are good. Except it will not completely test you entire scenario. If you have references outside of your solution (such as dll in the GAC, or dll from an SDK installed on your machine), creating a new workspace or deleting and getting latest code won't found those problems.
The only way to make sure is to pull down the code on another computer. If you don't have another computer handy, you can use a Virtual machine.
Do Get Specific Version and specify the latest. This will force TFS to download everything, ignoring the current synchronisation status.
TFS uses your workspace to know what is synched between the server and local.
I don't think there is an option to make Get Latest to behave like you want (Get Specific Version and specifying Latest Version and Overwrite).