hg: распространение изменений в n раз в две одинаково важные ветви

Question

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

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

В основном:

• assignment0
  • 1010 * Задача *
  • решение
• назначение 1
  • Задача
  • решение
• и т.д.

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

Что такое идеальный репозиторий / настройка / рабочий процесс ветвления, чтобы у меня был легкий доступ к различным итерациям и версиям фреймворка, и чтобы я мог легко распространять изменения в фреймворке на все другие ветви?

Варианты использования:

• изменение vectorlib с HLSL на GLSL
• добавление функции в 1-3 файла
• обычный, действительно

Answer 1

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

-- assignment 0 -----
                 \
                  \-- assignment 1----
                                   \
                                    \-- assignment 2 ----

Любое внесенное вами изменение / исправление будет внесено в самую раннюю ветвь назначения, к которой он относится. Затем он будет объединен с последующими назначениями.

-- assignment 0 ------------------------------------------
                 \
                  \-- assignment 1---- bugfix -------\----
                                   \                  \
                                    \-- assignment 2 --M--

Я думаю, что задачи и решения будут промежуточными шагами между заданиями. (Возможно, задачи и задания на самом деле одно и то же)

-- assignment 0 ------------------------------------------
                 \
                  \-- task 0 -- \ ---------------------------
                                 \              
                                  \-- solution 0 -- \ --------
                                                     \
                                                      \ -- assignment 1-------

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

Answer 2

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

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

Попытка визуального представления:

                  o -- o -- o [solution1] ------------------ o [solution2]
                 /                                          /
Base: o == o == o [assignment1] == o == o [assignment2] == o == o [assignment3]
                |\                      |\
Student 1:      | o -- o -- o ------------o (merge) -- o
                \                       |
Student 2:       o -- o -- o -- o ----- o (merge) -- o -- o

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

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