0

Background: We use a feature branching strategy to isolate change. Here's a quick diagram of what I mean. Nodes are branches, edges are parent/child relationships in TFS:

enter image description here

Most of the time we create feature branches on a per issue basis, so there are a lot of feature branches.

Also, for my purposes, I only care about migrating source control and changeset history. We don't use TFS work items, test cases, or test results.

Attempt 1: When I first ran the migration tool, it ran for about an entire day before filling up my hard drive and failing.

Attempt 2: Thinking that the 150ish feature branches were the culprit for the slowness/storage needs, I wanted a way to migrate only the "dev" branch of my "ecomm" team project collection in the diagram above. I did not see any way in the opshub tool to migrate a single branch.

I accomplished this by creating a new team project collection "ecomm-migration", then branched $/ecomm/dev to $/ecomm-migration/dev. Then I migrated the ecomm-migration team project collection (which only contains a single branch).

Everything seemed to work: I could see all my source files on Visual Studio Online. However, when I browsed the history of the ecomm-migration project that was migrated to Visual Studio Online, the history was lost: everything appeared to be committed as a single changeset, and annotating files reflected this as well.

Why didn't the changeset history get migrated? Am I doing it wrong? Does my approach of creating a separate team project collection to reduce the size of the team project collection being migrated interfere with the tools ability to migrate changeset history? Are there better tools/options for my scenario?

One thing I had previously considered was pruning dead feature branches with tf destroy, but it would be nice to avoid such drastic, irreversible, history destroying measures if possible.

I am using version 1.1.0.005 of the utility.

BenWillkommen
  • 1,472
  • 13
  • 21

1 Answers1

0

Can you please also share what is the version of the utility that you are using? You can find that from the About button on the utility left menu pane.

Addressing your concerns in points.

  1. The disk space requirements of the utility is equivalent to the size of your project. A good reference point would be to get the latest version of the project to your hard drive through Visual Studio and see the size. So that SIZE + 20% would be a good approximation of space that the utility will need in your C: drive during the migration process.

  2. While you did nothing wrong by branching your dev branch into a new project. The utility did nothing wrong either. When you migrated to VSO, you might have selected only the newly created project. Now in your VSO, the trunk of your data in the new project is not present. So, the utility converts Branch -> to -> Add. Which is the only sane way to migrate when source is not selected/available.

To get your desired result (of actual history) you will have to select all the projects where branch-merge was done (across projects) for migration. Which of course is nothing but what you did in Step 1.

Hence, we suggest you to migrate your original project, if you want to retain full history. We can work together to overcome the memory/space crunches that you are stuck in.

OpsHub Inc.
  • 1,095
  • 1
  • 6
  • 13
  • I've edited the original question to include the version number. I am back to the approach of migrating the ecomm project, however I am now getting a timeout exception at 1096/1668 changesets/labels in: https://gist.github.com/benwillkommen/895d83b1177354158372 I'm guessing I have to increase this timeout on my TFS server? If you have any guidance I'd love to hear it. – BenWillkommen Mar 23 '15 at 16:02