Перенос между ветками ms tfs с нарушением порядка следования

[virtuoso]

Спасибо за развёрнутый ответ.

Цитата:

Никакого нарушения порядка следования 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.

[sukhanchik]

Цитата:

Сообщение от virtuoso

Исправление руками делаем в PROD.
В ближайший перенос может быть changeset_1 или changeset_3: changeset_1 затрёт последние изменения, но это опять же правится руками на PROD (или повторной установкой changeset_2) после чего восстанавливается status quo. А в случае changeset_3 выполняем всё то же самое, что c changeset_2, и так вплоть до установки пропущенного changeset_1.
Разумеется, это ложится дополнительной нагрузкой на администратора, но данный случай полагается пока исключительным.

Ну собственно говоря - также выходили из ситуации. С дополнительной нагрузкой на администратора.
Понятно, что в идеальном случае либо получаются задержки, либо команда должна быть маленькой. Неудобство безусловно было - старались максимально разделять задачи, чтобы было минимум пересечений + некие ежедневные небольшие совещания по задачам с озвучиванием ситуации, чтобы минимизировать нагрузку на администратора и переложить обязанность по комментированию на автора разработчика. Но без работы администратор все равно не оставался ))