Мой код OpsHub и миграция рабочих элементов остановились на 70 % с ошибкой:
OH-SCM-002: Объект с внутренним идентификатором 9030 и глобальным идентификатором 10819 из XXX__TFS_Source_1416167909383_ALM_TFS_14161679093851416167909415 еще не был синхронизирован с целевой системой. Синхронизируйте сущность или удалите сопоставление сущности, чтобы продолжить процесс синхронизации.
Я понимаю, что причина этого, вероятно, в том, что рабочий элемент 9030 связан с набором изменений, в котором есть файлы для двух разных проектов (это была ошибка со стороны разработчиков). Другими словами, набор изменений 18909 (не упоминается в сообщении об ошибке, но упоминается в утилите миграции OpsHub «Ошибки контроля версий»), в котором были изменены файлы $/Proj1/FileA $/Proj2/FileB, связан с работой элемент 9030. $/Proj1 сопоставлен как часть миграции, $/Proj2 не сопоставлен.
До сих пор эта миграция заняла 11 дней, чтобы добраться до этой точки (завершено на 70%), поэтому я совсем не хочу удалять эту миграцию и начинать снова в соответствии с предложением по этому аналогичному вопросу: ошибки OpsHub OH-SCM-003 и OH-SCM-002 - Описание разрешения неясно
Мой вопрос:
а) С тех пор я удалил связь между рабочим элементом 9030 и набором изменений 18909, но ошибка все еще возникает. Ожидается ли это?
б) Есть ли способ заставить утилиту переноса OpsHub игнорировать этот набор изменений? Мне не нужно переносить код в $/Proj2, а также не нужно переносить рабочий элемент 9030. Было бы даже приемлемо, если бы этот набор изменений был вообще пропущен.
