Да, понятно, но мы с вами по-моему несколько все усложнили)
Я могу перефразировать вопрос так: отслеживает ли система откуда и какие именно атомарные изменения пришли. если они прошли через несколько разных веток?
Я так понимаю по нашей дискуссии, что и для mercurial, ответ все-таки нет.
Да, вы правы, теперь мы так и делаем, попытка «множественного наследования» оказалась неудачной, думаю она в принципе не реализуема на современных системах, т.к. в ней нет потребности.
Спасибо за подробный ответ.
Попробую объяснить зачем мы используем атомарные мержи)
Мы разрабатываем веб-проекты на основе собственного платформы, которая представляет собой некий минимальный сайт с базовыми возможностями. При создании нового проекта мы ответвляем его от ветки платформы и добавляем нужную в данном конкретном случае функциональность. И конечно же в процессе этого мы исправляем и дополняем общий функционал, причем изменения, специфичные для проекта произвольно чередуются с изменениями в общей платформе, и их мы потом и переносим выборочно на исходную ветку платформы.
По-моему, это самый очевидный и прямой путь, как по-другому это можно организовать?
Если есть программная платформа, на основе которой строятся все проекты, то изменения уже делятся на два класса — нужные только в конкретном проекте и полезные для платформы в целом. Вы ответвляете проект, вносите ив него и первые, и вторые изменения, а потом только вторые переносите обратно на ветку платформы. Разве это не типичный сценарий использования?
Видите в чем суть, на шаге 7 в моей схеме все три ветки разные, в вашей схеме вы каждым мержем переносите все возможние изменения с одной ветки на другую, я же говорю о выборочном переносе только некоторых изменений.
> Попытка слить 2 и 6 в 7 одновременно лишена смысла, т.к. изменение 2 уже содержится внутри 6.
Как это? Изменения 2 и 6 — это два совершенно разных изменения, в одном мы делаем что-то одно, а в другом — что-то другое.
Смотрите, допустим этот проект вначале состоит из одного файла содержащего три строки, все это на всех трех ветках:
А А А
Б Б Б
В В В
2. На стволе добавляется строка
А А А
Б Б Б
В В В
Г
3. На правой ветке строка 1 изменена
А А АА
Б Б Б
В В В
Г
4. Переносим изменение 3 на ствол
А АА АА
Б Б Б
В В В
Г
5. Строка 2 на правой ветке изменена
А АА АА
Б Б ББ
В В В
Г
6. Переносим изменение 5 на ствол
А АА АА
Б ББ ББ
В В В
Г
7. Переносим изменения 2 и 6 на левую ветку
А АА АА
ББ ББ ББ
В В В
Г Г
8. Переносим изменение 3 с правой ветки на левую
АА АА АА
ББ ББ ББ
В В В
Г Г
9. Пытаемся перенести изменение 5 (ББ) с правой ветки на левую - получаем конфликт
Не совсем так, на схеме изображены три ветки одного и того же проекта, время идет снизу вверх. Стрелки — это merge, т.е. перенос какой-то правки или их группы с одной ветки на другую. Вот история этой схемы:
1. От ствола ответвляются правая и левая ветки.
2. На стволе производятся изменения.
3. На правой ветке производятся изменения.
4. Изменения 3 переносятся на ствол.
5. На правой ветке еще производятся изменения.
6. Изменения 5 переносятся на ствол.
7. Изменения правок 2 и 6 переносятся на левую ветку.
8. Изменения 3 с правой ветки переносятся на левую.
9. Изменения 5 с правой ветки переносятся на левую.
Я могу перефразировать вопрос так: отслеживает ли система откуда и какие именно атомарные изменения пришли. если они прошли через несколько разных веток?
Я так понимаю по нашей дискуссии, что и для mercurial, ответ все-таки нет.
Попробую объяснить зачем мы используем атомарные мержи)
Мы разрабатываем веб-проекты на основе собственного платформы, которая представляет собой некий минимальный сайт с базовыми возможностями. При создании нового проекта мы ответвляем его от ветки платформы и добавляем нужную в данном конкретном случае функциональность. И конечно же в процессе этого мы исправляем и дополняем общий функционал, причем изменения, специфичные для проекта произвольно чередуются с изменениями в общей платформе, и их мы потом и переносим выборочно на исходную ветку платформы.
По-моему, это самый очевидный и прямой путь, как по-другому это можно организовать?
Как это? Изменения 2 и 6 — это два совершенно разных изменения, в одном мы делаем что-то одно, а в другом — что-то другое.
Смотрите, допустим этот проект вначале состоит из одного файла содержащего три строки, все это на всех трех ветках:
А А А Б Б Б В В В 2. На стволе добавляется строка А А А Б Б Б В В В Г 3. На правой ветке строка 1 изменена А А АА Б Б Б В В В Г 4. Переносим изменение 3 на ствол А АА АА Б Б Б В В В Г 5. Строка 2 на правой ветке изменена А АА АА Б Б ББ В В В Г 6. Переносим изменение 5 на ствол А АА АА Б ББ ББ В В В Г 7. Переносим изменения 2 и 6 на левую ветку А АА АА ББ ББ ББ В В В Г Г 8. Переносим изменение 3 с правой ветки на левую АА АА АА ББ ББ ББ В В В Г Г 9. Пытаемся перенести изменение 5 (ББ) с правой ветки на левую - получаем конфликт1. От ствола ответвляются правая и левая ветки.
2. На стволе производятся изменения.
3. На правой ветке производятся изменения.
4. Изменения 3 переносятся на ствол.
5. На правой ветке еще производятся изменения.
6. Изменения 5 переносятся на ствол.
7. Изменения правок 2 и 6 переносятся на левую ветку.
8. Изменения 3 с правой ветки переносятся на левую.
9. Изменения 5 с правой ветки переносятся на левую.