3

I have been doing some mock migrations from our On-Premise TFS server up to VSO on-and-off for over a month now using TFS Integration Services, but it is full of quirks. Microsoft just announced a new tool that is free from OpsHub (Visual Studio Online Migration Utility). I'm trying it out but I'm receiving the following error which I never saw with the TFS Integration Tool:

OH-SCM-009: Error occurred while sync. No matching items found in $/Proj/Release/0.29/CodeSmith Templates on the server, or you do not have permission to access them. It seems changeset has items across team projects and all such projects are not selected in configuration. Please create new configuration selecting all such projects to allow processing of this changeset.

I can't find any information about this error code. Does anyone know what is causing this? Thank you.

I am only migrating source code, no work items.

I have tried "Retrying" a few times and when it starts it takes about 15 minutes before it fails again, but it made no progress. This particular changeset that it fails on was merging two branches.

Screenshots: enter image description here

enter image description here

Any ideas?

EDIT 2014-05-14:

I am not able to choose a Project (below the Project Collection) for the source or destination - is this a bug? Oddly, when I do choose "Default Collection" for the destination, it only shows me the VSO hostname, but not the "\DefaultCollection" like the source does.

Not being able to choose the Project was a problem, because I wanted this to run against a "ProjectOpsHubTest" project, but instead it started appending changesets to my existing one that was successfully imported from TFS Integration Tools (fortunately we haven't made the final switch, so I've deleted it and started over). I still have the same problems with changeset 1550.

enter image description here

We have upgraded TFS several times since this checkin 1550 occured (I think 1550 was on TFS 2008, then we had 2010 I think, and now 2012), but I was able to do the migration just fine with TFS Integration Tools. I also don't think we've ever changed the Project name or ProjCollection names...

Adam Plocher
  • 13,994
  • 6
  • 46
  • 79
  • Never used this tool, but did several VC synchronizations, so just guessing ;) The branches that are merged in changeset 1550 are both included in the synchronization or is one of them in another TeamProject (as the error mentioned)? If not, are both branches existing on VSO and are able to be merged (branch relation existing)? Anything else happens during the changeset, e.g. renaming or deletion? – MikeR May 14 '14 at 09:10
  • It actually looks like the changeset has items from more than one team project and you'll want to select all of the team projects to be migrated that may contain changes in that changeset. For example, if the changeset contains changes from Project A & Project B, be sure to select both Project A & Project B during your migration. – Ed Blankenship May 14 '14 at 14:35
  • Does VSO support Active Directory Federated Services yet? I've been waiting on that feature for years. Without it I can't migrate my on-prem TFS to VSO. – Christopher Painter May 15 '14 at 23:48
  • Nope, at least I don't think so. I am using Azure with organizational accounts for just about everything that links to Azure. I believe the Org Accts are based on stripped down AD of sorts. VSO is the only component in the Azure dashboard where I still have to use a Microsoft account to login (does that answer your question?). EDIT: I forgot they have AD in Azure which is how you manage your Organizational Accts, so it's probably fair to say you can't do it. I think I read it's on their roadmap. – Adam Plocher May 15 '14 at 23:51
  • What is the reason that you switched from TFS Integration to the OpsHub tool? – MrHinsh - Martin Hinshelwood May 19 '14 at 04:24
  • @MrHinsh curiosity was a big part of it :). I was mainly hoping that the changeset history would actually have the correct timestamps and users associated to it (instead of just being a part of the description), but that doesn't seem to be the case. Also, TFS Int was fairly problematic and I wanted to see how OpsHub compared - but TFS Int always worked after a few tries or attempts at resolving the conflicts. Unfortunately, with OpsHub this problem seems to be something I have no way of resolving without buying the non-free one... ? – Adam Plocher May 19 '14 at 07:20
  • The OpsHub tool is really just a sales funnel into the very expensive main set of tooling so I don't see OpsHub investing in it beyond what fulfils their upsells...you could say they will actively NOT solve particular issues so that you are forced to buy their other tools :) – MrHinsh - Martin Hinshelwood May 19 '14 at 10:48
  • 1
    @Adam Plocher: Can you please zip up and send us the log files from location :\Program Files\OpsHub Visual Studio Online Migration Utility\logs and email them to ovsmu@opshub.com (Apologizes could comment earlier as needed to have reputation above 50 for commenting). As long as your use case is with in the free utility parameters, you should not have to buy anything. Utility is actively maintained – OpsHub Inc. May 21 '14 at 22:50
  • Thanks, just sent them over. I'm not seeing anything relating to OH-SCM-009 (the error) or 1550 (the changeset) in any of the files, though. – Adam Plocher May 22 '14 at 04:39

3 Answers3

2

This is usually due to nested branching issues. I do not believe that there is any way around it with the OpsHub tool limitations but you can get around it with the TFS Integration Tools.

If you cloak the problematic folder in the configuration file it will get past the error. Obviously though it has not added something to the server. You will, when it tries to branch from the cloaked folder, be asked to change the 'branch' to and 'add' to resolve the issue.

  • That doesn't seem to be correct... It actually looks like the changeset has items from more than one team project and you'll want to select all of the team projects to be migrated that may contain changes in that changeset. For example, if the changeset contains changes from Project A & Project B, be sure to select both Project A & Project B during your migration. – Ed Blankenship May 14 '14 at 14:36
  • Thanks for the responses. I didn't have any problem with this changeset or folder using TFS Integration Tools (I did cloak some of my process templates folders, but those were separate from this). – Adam Plocher May 14 '14 at 16:55
  • You will likely find that there used to be another Team Project that had code that was branched into this one. At some point that project was deleted. Thus the error. – MrHinsh - Martin Hinshelwood May 16 '14 at 04:53
  • @MrHinsh I have the same problem with opshub. I am using TFS integration tools now and not able to connect to my VS online account. It comes up with code 203: non-authoritative information. Any help much appreciated. Thanks – Suhumar Aug 19 '14 at 09:54
  • 1
    I figured out the issue. I used TFS 2011 provider and was able to connect to my cloud space. – Suhumar Aug 19 '14 at 10:54
1

From your description: "This particular changeset that it fails on was merging two branches."

If changeset has been merged from a different project that which is not selected while OpsHub Migration Utility then this issue may occur.

For example, you have two project source and branch. if you have changeset NNN which merge files from branch to source. And In OpsHub Migration Utility if you just select source project for migration Then you can get this error while processing NNN change set because OpsHub could not able to find from which changeset it is merged.

Another reason for this error is that the user configured to read the local TFS instance does not have admin privileges (and hence is not able to read the metadata details of this changeset). Please make sure that the user configured on the local TFS side (and also VSO side) has admin privileges.

You can delete project in VSO and create new configuration selecting all such projects to allow processing of dependent changeset.

OpsHub Inc.
  • 1,095
  • 1
  • 6
  • 13
  • Thanks for the response. I should only have one Project and one Project Collection. That has never changed as far as I know. Ops Hub only lets me select the Project Collection, but not the project itself. I updated my question with a new screenshot and some more information about the projects. Thanks – Adam Plocher May 14 '14 at 17:09
  • 1
    Adam, this is a limitation of the free OpsHub tool...I would recommend that you continue with the TFS Integration Tools – MrHinsh - Martin Hinshelwood May 19 '14 at 04:24
  • 1
    @MrHinsh thanks for the information. I will proceed with TFS Int. Tools like you recommend. Can you explain what the actual limitation is? Honestly, I don't really need my history that far back (would be nice, but I can survive without it) - do you know if there's a way to rollup all history beyond a certain point into one changeset and purge individual changeset history older than X years? – Adam Plocher May 19 '14 at 07:13
  • There are a number of limitations (well described in their brochure) however you can do what you want with the IFS IP. You can start the migration from any point so it should be possible to manually migrate the tip that you want and then push history on top. – MrHinsh - Martin Hinshelwood May 19 '14 at 10:50
  • The utility allows you to select specific projects to migrate. The project selection is done after the initial connectivity screen (for initial connectivity one only needs to select the collection). Project selection is at step 3 of the configuration process (connectivity information is needed to fetch project information) – OpsHub Inc. May 21 '14 at 22:58
0

I have the same error, and message is not explicit I assume. Problem is that you do not have access to a specific Work item due to explicit permission. You could check wich file doesn't inherit permission using the following link. Personally, it save my day: https://blogs.msdn.microsoft.com/congyiw/2011/10/20/tfs-version-control-permissions-why-cant-i-branchrenamedelete-x/

Nicolas
  • 47
  • 3