Примеры использования Mercurial Patch Queue - PullRequest
4 голосов
/ 05 ноября 2010

Я использую ртутные патчи в следующих случаях: -

  1. Когда мне нужно извлечь из удаленного хранилища и получить неподтвержденные незафиксированные изменения . Затем я просто создаю патч, qpop, извлекаю его из удаленного репозитория и снова импортирую патч.
  2. Когда мне нужно загрузить патчи в рецензии . Я просто делаю патч и загружаю его.

Как еще вы используете Mercurial Patch Queues? Я чувствую, что это очень мощное расширение Mercurial и что я не использую его в полной мере.

Ответы [ 4 ]

7 голосов
/ 05 ноября 2010

В Mercurial wiki есть хороший раздел на случаи использования:

В итоге:

  1. Сохранение текущего состояния рабочей копии, чтобы вы могли легко вернуться к ней позже
  2. Предотвращение «запутанной рабочей копии» - если вы на полпути к изменениям и хотите изменить что-то еще
  3. Обеспечивает изменяемые, переставляемые коммиты, так что вы можете получить «историю», выглядящую прямо перед нажатием.
4 голосов
/ 16 февраля 2011

Когда вы создаете очередь исправлений в Bitbucket, на правой панели перечисляются некоторые наиболее распространенные способы использования очередей исправлений.Их объяснение очень хорошее и отвечает на ваш вопрос напрямую.Цитаты из этого ниже.

Очереди исправлений хороши для:

  • Разработка функций, которые вы намереваетесь представить для апстрим-обзора

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

  • Экспериментируя с добавлением новой функции

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

  • Ведение личных настроек для другого проекта

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

Очереди исправлений не хороши для

  • Длительные ветви

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

  • Разработка группы

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

4 голосов
/ 05 ноября 2010

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

Пример:

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

На этом этапе мы клонируем базу данных и фиксируем изменения, которые мыможно вытащить.

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

Вернуться в исходную базу данных ...

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

Так что мораль в том, что вы можете просто вытащить и обновить, даже с незафиксированными изменениями.Если возникают конфликты слияния, также происходит нормальное поведение слияния.

Для экспорта исправлений hg export <rev> будет экспортировать исправления для проверки.

1 голос
/ 05 ноября 2010

MQ - отличный инструмент для управления параллельной разработкой.Явный самоплагиат и самореклама из моего собственного ответа :

3 Используйте MQ с одним патчем (или несколькими последовательными патчами) на проект.

  • Плюсы: просто и легко.
  • Минусы: необходимо qrefresh до переключения и перестроить после;сложно и рискованно, если проекты не являются ортогональными.

4 Используйте одну ветвь MQ для проекта.

  • Плюсы: сверхгибкий и масштабируемый (для количества одновременных проектов)
  • Минусы: необходимо qrefresh и qcommit до переключения и после перестройки;чувствует себя сложным.
...