Спасибо за развёрнутый ответ.
Цитата:
Никакого нарушения порядка следования changeset-ов tfs не допустит..
я понимаю под нарушением порядка именно порядок changeset'ов, который установился на DEV и установку на PROD в обратном порядке.
Цитата:
...как так получилось, что переносится модификация, зависящая от той модификации, которая еще не перенесена.
в этом как раз суть проблемы: нужно перенести модификацию changeset_2 скорее по требованиям пользователей, но логической связи с changeset_1 она не имеет, т.е. простым комментированием кода changeset_1 внутри changeset_2 получаем требуемый результат
Цитата:
1. Да, действительно зависимость между модификациями есть. Откатываем переносимую модификацию и ждем доработки первой модификации (с methodA())
в примере подразумевается, что между changeset_1 и changeset_2 нет логической связи, т.е. changeset_2 можно простыми комментариями "отвязать" от changeset_1, и результат от этого не пострадает.
Цитата:
Вручную можно исправить - вопрос в какой ветке?
Исправление руками делаем в PROD.
Цитата:
Если в PROD - то это исправление будет "жить" до ближайшего переноса какого-нибудь changeset-а с этим кодом и проблема встанет снова.
В ближайший перенос может быть changeset_1 или changeset_3: changeset_1 затрёт последние изменения, но это опять же правится руками на PROD (или повторной установкой changeset_2) после чего восстанавливается status quo. А в случае changeset_3 выполняем всё то же самое, что c changeset_2, и так вплоть до установки пропущенного changeset_1.
Разумеется, это ложится дополнительной нагрузкой на администратора, но данный случай полагается пока исключительным.
Вопрос достаточно актуальный, потому что в разнородных командах очевидно не получается
Цитата:
тщательно следить за зависимостью модификаций друг от друга
, что приводит только к простоям changeset_2 (в ветке DEV) в ожидании готовности changeset_1. Т.е. установка одного из проектов (к нему относится changeset_2) просто искусственно задерживается до готовности всех модификаций в прорядке check-in'ов на DEV.