we have a TFS server configured on a machine. Now the organization has moved the complete VM to their other location with a new IP assigned to that VM. It's a clone of that old VM and after its migration, we also pushed some code the old running TFS.
Now the query is that how can we configure Visual studio to point to the new server and how can we effectively push the new code committed on the old server meanwhile the migration was underway.
If we have the latest code on say, a certain machine, can we just add a new connection , remove the old one and check for any changes visual studio shows to be pushed to the new server ?
our concern is only the code repository and nothing else (tasks, bugs etc.)
any help appreciated
When a TFS server is cloned, you should be able to update the connection to use the new URL. Existing workspaces will automatically be remapped.
There is no easy way to push the missing checkins from one serves to another. Especially when they share the same server identity (since the Client object model assumes it's the same serves, in the same state and keeps swapping over the workspace state and caches).
You can create a single new checkin with the new state though.
Make sure you are connected to the new server. (Turn off old server if possible).
Create a workspace matching the one you have locally. Make sure it's of the "Local Workspace" variety
Get latest version
Delete all the local files, but keep the $tf folder.
Paste the most up-to-date copy of the code into your new workspace
Resolve any renamed files from within Team Explorer.
Check in your changes.
Related
I have a solution on TFS "Project One".
"Project One" was copied via external to another device of mine and i needed to map the solution on the new device to source control. Once i mapped the project, it replaced all the source that was local with whatever was last on TFS for the project. Any way i can get my local source back or is it gone forever?
I had not done any backups on the local code as i didn't think it would delete my current source. In fact i thought it would as me to do a merge.
I had a look at this link after my code had been replaced
Unfortunately you've lost the changes as TFS has overwritten the local files. You set up the workspace after making the changes so TFS didn't know anything about them in order to merge.
If you created any additional files that weren't under source control then they should still exist locally, so maybe you haven't lost everything
In future, if you setup the workspace first then you can obviously make changes to the files and TFS will know about it.
Alternatively, map the workspace to a different local folder and then copy in your changes. If you are using a local workspace then TFS will generate the pending changes for you.
The company I'm working at is moving TFS to a new server (and new user accounts since now we are using domain accounts). The previous server was on version 2012.4 Express and the new is using TFS 2013 Express.
To do this, I backup the old server databases, migrated them to the new server by using the utilities provided for that matter and ran the upgrade wizard.
The only problem I'm having now is that I can't map the projects to the previous locations on this since it keeps telling me that the project is locked in my previous workspace.
I've used a couple methods that should have worked but keep getting the same error:
Invoked the webservice StapWorkitemCache at http://ServerName:8080/tfs/WorkItemTracking/v3.0/ClientService.asmx both on the new and the old server
Ran witadmin rebuildcache /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName both on the new and the previous server
Deleted VersionControl.config from my computer
Deleted the workspaces by connecting to both the servers on Visual Studio and removing any workspace that I had.
I just keep getting the same error saying that the local folder is locked to the old workspace. How can I solve this once and for all?
EDIT:
Is it possible that I should be migrating just the TFS_DefaultCollection database instead of bringing the TFS_Configuration along?
EDIT 2
New problem arose:
Nobody can see their projects on the old server. Since I couldn't get the new server to work, I put the old one back online and now nobody can connect and on the web administration page there aren't any projects.
I have the following TFS upgrade scenario: I'd like to change my current TFS 2010 environment to TFS 2012 - this by moving the 2010 server to a new machine with another computer name.
Therefore I simply use the backups of the TFS 2010 databases from the old server and restore them on the new server. Before starting the backup I will turn off several TFS specific services on the old machine to avoid check-ins from devs. In the meantime the developers are working in offline mode. Afterwards I'm going to upgrade the databases.
Now it's getting interesting: The TFS 2012 is up and running with the upgraded project collections and everything works smoothly, but what happens to the local workspaces which are linked to the old TFS url? Is it possible that the developers can switch their exisiting workspaces with their pending changes to the new TFS 2012 url?
If yes, how can I do that? I've already did a test installation and upgraded to 2012 successfully, but I can't find out how to bind my existing workspaces with my pending changes to the new TFS. Initially I thought that the "Change Source Control" dialog could do the trick, but everything I'm able to click in the toolbar are the "Bind/Unbind" and "Refresh" buttons...
If no, I guess I have 2 options:
All I can do is forcing everyone to check-in/shelve and create a new mapping for the new server
OR
simply keeping the old TFS name/url? (Are the pending changes still available in this case?)
Thank you in advance!
P
Workspaces are stored on the server, so when the users add the new server they should find their old workspace already setup for them. Complete with all their existing checkouts etc.
If this doesn't work for a user, they can map a new workspace to the same directory, checkout all files in the tree, then use the tfs power tools do to a uncheckout unchanged (tpft uu /noget) to only leave their changed files checked out.
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).
is there a (simple) way to move a single TeamProject from one server to another? Including source code, work items, documents, project site...
We don't want to move our server from one machine to another. Just a single project from server A to server B.
You have two options
You can use the TFS to TFS migration tool: Click Here. This doesn't include the WSS project site.
Or you can backup your TFS db and restore on a new TFS instance, then use the TFSDeleteProject.exe tool to remove the projects you don't want.
The latter option is the easiest, but will not merge the backed up projects with any existing projects on the target instance. Existing projects will be lost. WSS sites can also be moved in this manner as well. See How to: Back Up a Team Foundation Server
The TFS to TFS migration tool is obsolete. The features you are looking for is part of TFS Integration Platform.
Goto http://tfsintegration.codeplex.com/ for more info.
In TFS 2010 you can detach the Project Collection database using the TFS Admin Console and then re-attach it to another TFS Server.
http://msdn.microsoft.com/en-us/library/dd936138.aspx
If you want an entire Project Collection to be moved from one TFS server to another:
1) Detach the collection via Admin Console.
2) Backup the Tfs_SomethingCollection database using SSMS, then restore it to the other database server.
3) On the second TFS Admin Console, attach the project collection. It will show up as an available collection to attach just because it has been restored in the second sql server instance.
I did not migrate the Tfs_Configuration database. In my case I was not utilizing reporting services, build services, or sharepoint.
I hadn't installed the second TFS server and was wondering, what options to choose when installing, and if you should install it after or before restoring the migrated DB(it doesn't really matter): Install TFS on the second machine. If TFS and its database instance will be on seperate servers, then choose Advanced configuration and specify the name of the DB server instance. When you have an opportunity to create a DefaultCollection, then opt to skip that step. The install will create a new Tfs_Configuration DB on the new server. Then follow the above steps to migrate the collection DB to the new DB server instance and attach it.
Programmers will need to add the new server to Team Explorer, and hit Change Source Control... twice in a row for each solution. Make sure the local path mappings are correct, and then Bind each solution/project.