Как получить разную проблему в Accurev без каких-либо унаследованных изменений?
Хотя я не уверен, что у меня есть удовлетворительный ответ на другой мой вопрос по Accurev, я полагаю, что начинаю понимать проблему, с которой я сталкиваюсь при использовании различий Accurev.
Поток примерно такой:
- Разработчик А вносит некоторые изменения для ошибки 1, продвижение.
- Разработчик А вносит некоторые изменения в баг 2, продвигает.
- Разработчик B просматривает изменения разработчика A для ошибки 1 и отправляет ее обратно для дальнейших изменений.
- Разработчик C рассматривает изменения разработчика A для ошибки 2 и утверждает их, дополнительное продвижение.
- Разработчик А вносит больше изменений в баг 1, продвигает.
- Разработчик C рассматривает изменения разработчика A для ошибки 1.
Последний шаг, где я чувствую поломку. Разработчик C не может каким-либо рациональным образом увидеть все изменения, связанные с ошибкой 1, даже если каждая транзакция / версия (независимо от того, как их называет Accurev) связана с этим идентификатором проблемы.
Если я делаю сравнение с базой, я получаю все изменения в баге 2, а также все остальное, что было продвинуто. Умножьте это на 30 разработчиков, и это кошмар.
Это становится очень грязно, если есть совпадения и разрешение слияния, но давайте предположим, что на данный момент атрибуция не ошибается, кроме как в этом случае... даже если я видел, как это происходит иначе, это может быть просто недоразумением.
В любом случае, предполагая, что все продвижения были "чистыми" и (насколько я понимаю) новые транзакции являются "псевдонимами" транзакций каждого разработчика, "сохраняющими" транзакции.
Как просмотреть комбинированные различия двух транзакций?
Конкретно транзакции на шаге 1 и шаге 5 выше. Будет две транзакции, и мне нужны только изменения, сделанные в этих транзакциях, и только эти транзакции. В идеале, хорошо отформатированный или графический инструмент различий, который работает рекурсивно (не для отдельных файлов, в целом).
Обратите внимание, что правильные ответы могут быть "Вы делаете это неправильно", но должны содержать конструктивные предложения о том, что изменить, например "Делайте свои обзоры в рабочей области разработчика" или аналогичные. Я подозреваю, что мы можем просто использовать это неправильно.
2 ответа
Я считаю, что нет способа просмотреть изменения данного разработчика в файле после того, как эти изменения были продвинуты, когда есть несколько наборов изменений для этого файла.
Дифференцирование против резервной копии не имеет смысла в родительском потоке, не являющемся рабочим пространством.
Отличие от основы имеет все изменения.
Смотрите комментарии к принятому ответу В чем разница между основой и поддержкой в Accurev.
Я бы не сказал, что вы делаете это неправильно, но есть определенные предположения, которые необходимо сделать здесь. С моей стороны, из вашего описания видно, что вы явно используете один файл в примере (во всяком случае, для упрощения) и что изменения вносятся последовательно.
В AccuRev пакет изменений содержит контекст любого файла, связанного с "ошибкой" от основания до головы. Поэтому, когда разработчик исправил ошибку 1, "начальная" и "конечная" версии файла были отнесены к ошибке 1. Независимо от того, что на данный момент делают другие 30 разработчиков, вы всегда можете просмотреть пакет изменений для ошибки 1. посмотрите на вкладку изменений и измените файл только в том случае, если он относится к этой ошибке, даже если в этот поток внесены тысячи дополнительных изменений.
Трудность возникает из-за того, что разработчик предположил, что он все сделал, внес последующие изменения в файл, который был частью ошибки 1, связал его с ошибкой 2 и пошел дальше. Когда проверка завершена, и теперь он должен внести дополнительные изменения в ошибку 1, они создаются поверх изменений ошибки 2.
Прежде всего, AccuRev не позволит вам продвигать этот файл и связать его с ошибкой 1, если вы не решите "Изменить слияние пакетов". Это означает, что существует пробел в присвоении версий конкретной ошибке, с которой вы хотите связать - в частности, изменениям в Bug 2. AccuRev хочет, чтобы вы подтвердили, что эти изменения Bug 2 в порядке, что они неявно включены в Bug 1. исправить. Так что мы не позволим этому случиться просто случайно. Однако, если вы решите, что вы не хотите, чтобы изменения в Bug 2 присутствовали в содержимом Bug 1, вам придется внести некоторые исправления. Это усложняется при описанном вами рабочем процессе, но определенно возможно. Суть в том, что вы представили сценарий, в котором ни один инструмент не сможет автоматически обработать, потому что есть последовательные изменения, связанные с различными ошибками. Что ж, позвольте мне изменить это и сказать, что никакой инструмент, который работает вне таких вещей, как "проверка в комментариях" и предоставляет автоматизированные способы работы на уровне проблемы вместо уровня файла, не будет. Пакет изменений AccuRev очень мощный и предоставляет контроль в ваши руки, позволяя вам работать с CP как объектом на протяжении всего процесса разработки.
Я надеюсь, что это ответит на ваш вопрос максимально подробно на этом форуме. Если у вас есть дополнительные вопросы или вы хотите обсудить их более подробно, мы также можем это организовать.
Ура,
~ Джеймс