1

We have some huge changesets that are causing our migration to grind to a crawl. I am wondering if we delete those folders from the project, will OpsHub still migrate the changesets for the delete folders?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Bill G
  • 27
  • 6

1 Answers1

0

Destroying folders will remove them and all their history (in that path) from the version control data store. OpsHub won't be able to find the folders and as such will not migrate them (they don't exist). You will have to restart the migration. If folders have been renamed, you may need to destroy the data under the old name as well.

Deleting folders won't exclude them from migration. OpsHub will replay all actions and will detect these changes and their history. It will migrate all changesets for the folder up to the final delete.

You can also speed up you migration a lot by destroying old branches (branches cause a lot of drag on your migration). If you have old branches or deleted branches that you don't need to transfer over, then destroy them. Especially Feature branches and old developer branches may not be worth the trouble.

You can also up the memory allocation for OpsHub to give it a little speed bump:

  • Close the migration utility.
  • Goto location C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHubServer6.0.16\bin
  • open the file service.bat in notepad in editable mode. You may need to start Notepad as administrator to edit it.
  • search for the keyword -Xms512m -Xmx2048m and replace it with -Xms1024m -Xmx4096m, this will increase the memory for java, save the above changes (The numbers are for reference. You can set a higher amount of memory based on your available hardware)
  • Go to the location from command prompt C:\Program Files\OpsHub Visual Studio Online Migration Utility\OpsHubServer6.0.16\bin
  • Run the unregisterservice.bat from command prompt as an admin to unregister the service.
  • Let the above command execute completely then run registerservice.bat as an admin for registering the service.
  • Start the utility and start the migration

Running it on you Application Tier or on a machine that's physically close to the Application Tier also speeds up migrations considerably, as it shortens the network round-trips for one side of the migration to nearly zero. Since the Application Tier receives the most requests, it makes sense to put the migration there and not close to Visual Studio Team Services (by installing it on an Azure machine for example). Ensure that the AppTier has enough disk space for its version control cache.

Also monitor your SQL server closely, querying some of the branch history can be very CPU intensive, some SQL server settings can make a big difference. Ensuring that there are multiple TempDb files is one, tweaking MaxDOP can be another. See some tips on optimizing your SQL server for TFS here.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341