Как получить разную проблему в Accurev без каких-либо унаследованных изменений?

Question

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

Поток примерно такой:

1. Разработчик A вносит некоторые изменения для ошибки 1, повышение.
2. Разработчик A вносит некоторые изменения для ошибки 2, повышение.
3. Разработчик B рассматривает Разработчик A изменения для ошибки 1 и отправляет его обратно для дальнейших изменений.
4. Разработчик C рассматривает Разработчик A вносит изменения для ошибки 2 и утверждает, дополнительное продвижение.
5. Разработчик A вносит больше изменений в ошибку 1, повышение.
6. Разработчик C рецензии Разработчик A изменения для ошибки 1.

Последний шаг - это то, где я чувствую разрыв. Разработчик C не может каким-либо рациональным образом увидеть все изменения, связанные с ошибкой 1, даже если каждая транзакция / версия (независимо от того, как их называет Accurev) связана с идентификатором этой проблемы.

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

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

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

Как просмотреть комбинированные различия двух транзакций?

В частности, транзакции на шаге 1 и шаге 5 выше. Будет две транзакции, и я хочу только изменения, сделанные в этих транзакциях, и только этих транзакций. В идеале, хорошо отформатированный или графический инструмент различий, который работает рекурсивно (не для отдельных файлов, в целом).

Обратите внимание, что допустимыми ответами могут быть «Вы делаете это неправильно», но они должны содержать конструктивные предложения о том, что нужно изменить, например «Делать свои обзоры в рабочем пространстве разработчика» или аналогичные. Я подозреваю, что мы можем просто использовать это неправильно.

Answer 1

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

В AccuRev пакет изменений содержит контекст любого файла, связанного с «ошибкой», от основания до заголовка. Поэтому, когда разработчик исправил ошибку 1, «начальная» и «конечная» версии файла были отнесены к ошибке 1. Независимо от того, что на данный момент делают остальные 30 разработчиков, вы всегда можете просмотреть пакет изменений для ошибки 1. Посмотрите на вкладку изменений и просмотрите файл only , поскольку он относится к этой ошибке, даже если в этот поток добавлено тысяча дополнительных изменений.

Там, где возникает трудность, заключается в том, что разработчик предположил, что он был сделан, внес последующие изменения в файл, который был частью ошибки 1, связал его с ошибкой 2 и продолжил. Когда проверка завершена, и теперь он должен внести дополнительные изменения в ошибку 1, они строятся на top изменений ошибки 2.

Прежде всего, AccuRev не позволит вам продвигать этот файл и связать его с ошибкой 1, пока вы не решите «Изменить слияние пакетов». Это означает, что существует пробел в присвоении версий конкретной ошибке, с которой вы хотите связать, - в частности, изменениям в Bug 2. AccuRev хочет, чтобы вы подтвердили, что эти изменения Bug 2 в порядке, что они неявно включены в Bug 1 исправить. Так что мы не позволим этому случиться просто случайно. Однако, если вы решите, что вы не хотите, чтобы изменения в Bug 2 присутствовали в содержимом Bug 1, вам придется внести некоторые исправления. Это усложняется при описанном вами рабочем процессе, но определенно возможно. Суть в том, что вы представили сценарий, в котором ни один инструмент не сможет автоматически обработать, потому что есть последовательные изменения, связанные с различными ошибками. Что ж, позвольте мне изменить это и сказать, что никакой инструмент, который работает вне таких вещей, как «проверка в комментариях» и предоставляет автоматизированные способы работы на уровне проблемы вместо уровня файла, не будет. Пакет изменений AccuRev очень мощный и предоставляет контроль в ваши руки, позволяя вам работать с CP как объектом на протяжении всего процесса разработки.

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

Приветствия
~ Джеймс

Answer 2

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

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

Разница с базой имеет все изменения.

См. Комментарии к принятому ответу В чем разница между основой и поддержкой в ​​Accurev .