Как сделать набор изменений в RTC (затмение) повторно редактируемым?

Question

Я отправил на рассмотрение набор изменений.К сожалению, я забыл сначала обновить свою песочницу, так что это означает, что я не включил некоторые изменения в этот набор.

Поэтому я потерял возможность добавлять изменения в свой набор изменений.

Я нене хочу отказываться от этого набора изменений, потому что он содержит важные изменения.Я также не хочу доставлять 2 набора изменений, потому что они содержат атомарную логику (логику, которая не может быть разделена).

У меня такое ощущение, что вариант "обратный" получит мойизменить набор обратно в редактируемое состояние, но я действительно не знаю, что здесь делать.

Подводя итог: мне нужно снова сделать мой набор изменений редактируемым, чтобы я мог объединить его с другим.

Кто-нибудь знает, как я это сделаю?

Спасибо, ребята, вы правите!

Answer 1

Я не думаю, что вы можете вернуться в изменяемое состояние для своего набора изменений, если этот набор изменений был "завершен" перед отправкой на проверку.

В этом случае «реверс» (т. Е. Создание нового набора изменений, отменяющего предыдущий набор изменений), за которым следует новый набор изменений, в котором вы повторяете свою работу и повторно отправляете ее на рассмотрение, могут быть Единственное решение.

Однако, следуя этому примеру проверки кода в RTC , наборы изменений должны быть изменяемыми во время обзора (чтобы первоначальный программист мог проверить новые версии своих файлов на основе отзывов рецензентов) ).

Answer 2

Вы должны создать новый набор изменений.

Я говорю это по двум причинам:

1) Эстетический аргумент в пользу наличия только одного набора изменений для каждого рабочего элемента на практике быстро ломается - изменение легко забыть, и вам, возможно, придется вносить изменения из-за ошибок или просмотра комментариев.

2) Наличие нескольких наборов изменений облегчает понимание ваших изменений. Каждый набор изменений может содержать логический набор изменений, поэтому один рабочий элемент может иметь три набора изменений: « Код рефакторинга », « Обновление авторских прав » и « Изменения» из обзора". Таким образом, когда кто-то аннотирует файлы в будущем, он получит что-то более детальное, чем исходный рабочий элемент.

Относительно аргумента "атомной логики" : это, вероятно, не проблема, если ваша команда не имеет привычки доставлять / отбрасывать отдельные наборы изменений. В проекте RTC мы регулярно делим логически дискретные изменения на несколько наборов изменений и несколько компонентов.

Если вы обеспокоены тем, что можете доставлять наборы изменений, которые логически зависят от изменений в других компонентах (как я иногда это делаю), я предлагаю вам вмешаться в bug 150421 . Ошибка 153907 описывает подобную проблему, но требует гораздо более сложного решения (что делает ее менее вероятной для реализации без давления со стороны клиента).

Answer 3

Я столкнулся с той же проблемой и решил создать патч, отменить мои изменения и затем создать новый набор изменений.