Миграция с локального TFS2012 на VSO TFS2013 с помощью OpsHub
Уже более месяца я выполняю некоторые фиктивные миграции с нашего локального TFS-сервера на VSO-on-off с использованием TFS Integration Services, но он полон причуд. Microsoft только что анонсировала новый инструмент, свободный от OpsHub (Visual Studio Online Migration Utility). Я пробую это, но я получаю следующую ошибку, которую я никогда не видел с TFS Integration Tool:
OH-SCM-009: Произошла ошибка во время синхронизации. Не найдено подходящих элементов в $/Proj/Release/0.29/CodeSmith Templates на сервере, или у вас нет прав доступа к ним. Кажется, у changeset есть элементы в командных проектах, и все такие проекты не выбраны в конфигурации. Пожалуйста, создайте новую конфигурацию, выбрав все такие проекты, чтобы разрешить обработку этого набора изменений.
Я не могу найти информацию об этом коде ошибки. Кто-нибудь знает, что вызывает это? Спасибо.
Я только мигрирую исходный код, никаких рабочих элементов.
Я пытался "повторить попытку" несколько раз, и когда он запускается, требуется около 15 минут, прежде чем он снова выходит из строя, но это не дает прогресса. Этот конкретный набор изменений, на котором он терпит неудачу, объединял две ветви.
Скриншоты:
Есть идеи?
РЕДАКТИРОВАТЬ 2014-05-14:
Я не могу выбрать проект (ниже коллекции проектов) для источника или места назначения - это ошибка? Как ни странно, когда я выбираю "Коллекция по умолчанию" для места назначения, он показывает только имя хоста VSO, но не "\DefaultCollection", как это делает источник.
Невозможность выбрать проект была проблемой, потому что я хотел, чтобы это работало с проектом "ProjectOpsHubTest", но вместо этого он начал добавлять наборы изменений в мой существующий, который был успешно импортирован из инструментов интеграции TFS (к счастью, мы не сделали последнее переключение, поэтому я удалил его и начал заново). У меня все те же проблемы с ревизией 1550.
Мы несколько раз обновляли TFS с тех пор, как произошла эта проверка 1550 (я думаю, что 1550 была на TFS 2008, тогда у нас был 2010, я думаю, а теперь и 2012), но я смог прекрасно выполнить миграцию с помощью инструментов интеграции TFS. Я также не думаю, что мы когда-либо меняли имя проекта или имена ProjCollection...
3 ответа
Обычно это происходит из-за проблем с вложенными ветвями. Я не верю, что с ограничениями инструмента OpsHub можно обойтись, но обойтись можно с помощью инструментов интеграции TFS.
Если вы замаскируете проблемную папку в файле конфигурации, она пройдет ошибку. Очевидно, что он не добавил что-то на сервер. Когда он попытается перейти из скрытой папки, вам будет предложено изменить "ответвление" на "добавить" и разрешить проблему.
Из вашего описания: "Этот конкретный набор изменений, на котором он не работает, объединял две ветви".
Если набор изменений был объединен с другим проектом, который не был выбран во время работы утилиты миграции OpsHub, то эта проблема может возникнуть.
Например, у вас есть два источника проекта и ветвь. если у вас есть набор изменений NNN, который объединяет файлы из ветви в источник. А в Утилите миграции OpsHub, если вы просто выбираете исходный проект для миграции, вы можете получить эту ошибку при обработке набора изменений NNN, поскольку OpsHub не смог найти, из какого набора изменений он объединен.
Другая причина этой ошибки заключается в том, что пользователь, настроенный для чтения локального экземпляра TFS, не имеет прав администратора (и, следовательно, не может прочитать подробности метаданных этого набора изменений). Убедитесь, что пользователь, настроенный на локальной стороне TFS (а также на стороне VSO), имеет права администратора.
Вы можете удалить проект в VSO и создать новую конфигурацию, выбрав все такие проекты, чтобы разрешить обработку зависимых изменений.
Я имею ту же ошибку, и сообщение не является явным, я предполагаю. Проблема в том, что у вас нет доступа к определенному рабочему элементу из-за явного разрешения. Вы можете проверить, какой файл не наследует разрешение, используя следующую ссылку. Лично это спасет мой день: https://blogs.msdn.microsoft.com/congyiw/2011/10/20/tfs-version-control-permissions-why-cant-i-branchrenamedelete-x/