SVN patch / diff management в проекте для нескольких человек - PullRequest
Новая
       36

SVN patch / diff management в проекте для нескольких человек

1 голос
/ 30 марта 2012

Обычно я работаю над небольшими проектами, в которых одновременно участвуют только 2-3 человека, работающих на одной и той же базе кода.

Обычная рутина для меня выглядит следующим образом:

  1. Просмотрите отчеты об ошибках, выберите ошибку по приоритету и напишите исправление
  2. Создать diff / patch (назовем это patch "alpha") изменений в кодовой базе (то есть: svn diff> ~ / diff_alpha.patch)
  3. Отправьте патч по электронной почте коллегам, чтобы они могли визуально проверить различия в базе кода и указать на ошибки или предложения
  4. Они сообщают мне, какие изменения требуются, я помещаю их, а затем пересылаю по электронной почте моей команде с измененным патчем
  5. Как только все согласятся с тем, что патч хорош, я применяю его к базе кода, объединяя изменения других людей, если это необходимо, пересобирая, повторно тестируя и фиксируя.

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

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

  1. Резервное копирование моей текущей работы в новый патч (то есть: патч "bravo") через svn diff> ~ / diff_ bravo .patch
  2. Вернуть мою текущую рабочую копию (svn revert -R.)
  3. Применить старый патч (patch -p0 <~ / diff_ <em>alpha .patch)
  4. Зафиксировать старый патч (svn commit)
  5. Примените патч, над которым я ранее работал (patch -p0 <~ / diff_ <strong>bravo .patch)
  6. Продолжить работу над кодом, связанным с diff_bravo.patch

Это раздражает, так как мне обычно приходится объединять конфликты между diff_alpha и diff_bravo.

Другим подходом, который я попробовал, было просто продолжить работу над diff_alpha без создания diff_bravo. Затем, когда я получаю одобрение на весь код в исходной diff_alpha, которую я отправил по электронной почте, я делаю следующее:

  1. Резервное копирование моей текущей работы в новый патч (то есть: патч "temp") через svn diff> ~ / diff_ temp .patch
  2. Вернуть мою текущую рабочую копию (svn revert -R.)
  3. Применить старый патч (patch -p0 <~ / diff_ <em>alpha .patch)
  4. Зафиксировать старый патч (svn commit)
  5. Примените патч, над которым я ранее работал (patch -p0 <~ / diff_ <strong>temp .patch)
  6. Теперь я могу продолжить то, что делал, не прибегая к ручному слиянию, но я получу тонны блоков ошибок в моей команде «patch», так как половина кода в diff_temp уже зафиксирована в diff_alpha. Я не считаю это приемлемым.

Любые рекомендации по обработке нескольких задач / ошибок в общем файле, чтобы я мог минимизировать конфликты SVN?

Ответы [ 2 ]

3 голосов
/ 30 марта 2012

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

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

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

Вы можете иметь несколько веток (по одной на каждую ошибку) и работать с ними одновременно.При слиянии с транком SVN должен выполнять слияние автоматически (иногда указывая конфликты, которые можно разрешить вручную.

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

ОБНОВЛЕНИЕ:На основании комментария Ленивого Барсука члены вашей команды могут установить мониторы коммитов, чтобы предупредить их, когда вы вносите изменения в (конкретную) ветку.

2 голосов
/ 30 марта 2012

Когда мы работаем, мы делаем большинство наших обзоров кода после того, как происходит фиксация.Ни один из файлов патча не идет туда-сюда.Мы используем Jenkins и у нас есть плагины, которые могут выполнять большую часть проверок за нас (например, Findbugs, PMD, CheckStyle и т. Д.).Если мы находим проблемы, мы можем исправить их в новом коммите.Если изменение было неудачным, мы можем отменить его.

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

У меня также есть плагин Commit Monitor для Subversion (действительно, после-коммитный хук), который позволяетустановить свои собственные предпочтения, о каких изменениях они хотят получать уведомления.Конфигурация хранится в репозитории, поэтому пользователи имеют к ней доступ.

...