Примеры использования Mercurial Patch Queue
Я использую ртутные патчи в следующих случаях:
- Когда мне нужно вытащить из удаленного репозитория и иметь невыполненные незафиксированные изменения. Затем я просто создаю патч, qpop, извлекаю его из удаленного репозитория и снова импортирую патч.
- Когда мне нужно загрузить патчи в обзоры. Я просто делаю патч и загружаю его.
Как еще вы используете Mercurial Patch Queues? Я чувствую, что это очень мощное расширение Mercurial и что я не использую его в полной мере.
4 ответа
В Mercurial wiki есть хороший раздел о случаях использования:
В итоге:
- Сохранение текущего состояния рабочей копии, чтобы вы могли легко вернуться к ней позже.
- Предотвращение "запутанной рабочей копии" - если вы на полпути к изменениям и хотите изменить что-то еще
- Обеспечьте изменяемые, переставляемые коммиты, чтобы вы могли получить "историю", выглядящую как раз перед нажатием.
Вам не нужны патчи 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> будет экспортировать патчи для просмотра.
Когда вы создаете очередь исправлений в Bitbucket, она перечисляет некоторые наиболее распространенные способы использования очередей исправлений в правой панели. Их объяснение очень хорошее и отвечает на ваш вопрос напрямую. Цитаты из этого ниже.
Очереди исправлений хороши для:
Разрабатывая функции, которые вы намереваетесь представить для последующего обзора
Поскольку исправления в очередях исправлений могут быть изменены, они предоставляют идеальный способ разработки функции с отслеживанием истории, в то же время позволяя легко включать обратную связь
Эксперимент с добавлением новой функции
Очереди исправлений не загромождают историю вашего проекта, поэтому вы можете безопасно использовать их как способ быстро опробовать идею и сохранить ее в управлении версиями, не загромождая историю вашего проекта неудачными экскурсиями. Если вы решили продолжить эксперимент, вы можете легко превратить очередь патчей в набор традиционных коммитов Mercurial.
Ведение личных настроек для другого проекта
Поскольку очереди исправлений не являются частью официального журнала изменений проекта, они идеально подходят для поддержки частных настроек для вышестоящего проекта. Например, вы можете поддерживать очередь исправлений, которая делает программу лучше интегрированной с рабочим процессом вашей компании
Очереди патчей не годятся для
Долгосрочные ветви
Поскольку очереди исправлений очень изменчивы, они плохо отслеживают долгую историю вашего исходного кода. По этой причине долгосрочные ветви, такие как те, которые соответствуют выпускам продуктов, должны храниться в репозиториях или именованных ветвях.
Групповое развитие
Очереди исправлений не отслеживают историю слияний, что делает их плохим выбором для групповой разработки, где вы действительно хотите увидеть, когда данный набор функций был объединен в хранилище. В случае сомнений следует придерживаться традиционного форка, но овладение мощью очередей исправлений даст вам огромную гибкость в рабочем процессе и предоставит вам значительно расширенные возможности совместной работы.
MQ - отличный инструмент для управления параллельной разработкой. Явный самоплагиат и самореклама из моего собственного ответа:
3 Используйте MQ с одним патчем (или несколькими последовательными патчами) на проект.
- Плюсы: просто и легко.
- Минусы: необходимо qrefresh перед переключением и перестроить после; сложно и рискованно, если проекты не являются ортогональными.
4 Используйте одну ветку MQ на проект.
- Плюсы: сверхгибкий и масштабируемый (для количества одновременных проектов)
- Минусы: должны qrefresh и qcommit перед переключением и перестроить после; чувствует себя сложным.
Я использую MQ для разработки поверх большого репозитория Subversion. Я не хочу проверять с помощью hgsubversion или чего-то подобного. В моей рабочей папке я создаю новое репозиторий.hg и Mercurial Patch Queue. Я отслеживаю ревизии svn с помощью HG и мои патчи находятся на вершине. Всякий раз, когда я чувствую необходимость обновить состояние svn, я вставляю все патчи, запускаюsvn updateи снова нажмите и обновите патчи. Когда я уверен, что моя серия подходит для фиксации, я могу доделывать свои патчи один за другим. (В настоящее время разрабатывается новая функция Subversion "полка", но каждый раз, когда я ее пробовал, она работала недостаточно хорошо, поэтому я все еще использую подход MQ.)