Когда вышла версия SVN 1.5, помню, мы с коллегами очень обрадовались долгожданной поддержке записи истории переноса изменений (слияния), которую до этого момента мы хранили в комментариях к правкам и это, конечно же, нас очень беспокоило.
На радостях нам в голову начали приходить различные идеи, как использовать эту новую возможность, и однажды мы решили с ее помощью реализовать модульность на уровне исходного кода.
Идея была не делать отдельные библиотеки, включаемые во время выполнения, как это обычно делается, а разделить повторно используемый в разных проектах функционал в отдельные ветки и при необходимости перенести их в новый проект. Мы взяли основную ветку платформы, отделили от нее около 5 модульных веток, в каждую из которых добавили функционал одного отдельного модуля и сохранили их актуальность, перенеся в них изменения из ствола.
Все шло хорошо.
Когда нам нужно было собрать дистрибутив, включающий несколько конкретных модулей, мы форкалили новый проект из ствола и последовательно переносили в него изменения из ветвей нужных модулей.
Но в процессе разработки конкретных проектов мы столкнулись с необходимостью доработок и исправлений их кода, как основного кода магистрали, так и кода наших псевдомодулей.
Естественно, эти полезные изменения нужно было перенести обратно в ствол и ветки модулей, чтобы они попали в будущие проекты, что мы и сделали.
И тут мы столкнулись с неожиданным для нас эффектом.
SVN хранит историю изменений, отправленных в ветку, в текстовом свойстве корневой папки.
Текст свойства представляет собой список веток, из которых когда-либо были перенесены изменения в эту, с указанием, какие ревизии были перенесены.
Итак, в нашем случае основная особенность реализации механизма смешивания в SVN заключается в том, что при любом переносе любых изменений, даже одной небольшой правки из одной ветки в другую, вместе с этой правкой полностью переносится и ВСЯ история слияний.
.
И вот что случилось с нами.
При переносе изменений в транк из проектов, содержащих модули, в транк переносились и записи об интеграции этих модулей.
А все последующие ответвленные от ствола проекты уже отказывались принимать код модуля, полагая, что эти изменения они уже получили ранее.
И мы поняли, что у SVN в нашем случае есть одно важное ограничение, смысл которого можно описать так: На путях передачи изменений невозможно образование замкнутых петель.
.
Мы пытались оптимизировать эти пути, придумывая различные правила, разделяли изменения на классы и задавали отдельные правила для каждого из них, но в итоге поняли, что всё это слишком сложно и неудобно, и отказались от идеи модульность на уровне исходного кода, которая нам так понравилась, заменяющая обычную модульность во время выполнения.
В последнее время я все чаще слышу от друзей восторженные отзывы о распределенных системах контроля версий, в частности Mercurial и Git. И у меня возник вопрос: можно ли организовать такую сложную схему передачи изменений на этих системах? Прошу людей, пользующихся упомянутой или другими системами, подсказать, можно ли в замкнутом цикле передавать в них изменения без возникновения описанной проблемы? Например, на следующей диаграмме можно ли выполнить редактирование слиянием 8? И заблокирует ли система еще раз попытку передачи 9? SVN, например, заблокирует оба.
ВВЕРХ: цлом говорит, что Git позволит внести обе правки и, естественно, создаст коллизию в 9-м.
Вообще, в SVN можно тоже игнорировать блокировки, тогда эффект будет тот же.
ВВЕРХ: PQR предположил, что в Mercurial правки можно атомарно переносить с помощью расширения Transplant, а в Git — с помощью команды Cherry-Pick, но, судя по всему, в обоих случаях будут разрешены обе правки (8 и 9).
Теги: #svn #системы контроля версий #системы контроля версий
-
Летайте С Wi-Fi Рейсами Oman Air
19 Oct, 24 -
Коралловые Рифы
19 Oct, 24 -
Дино Эспозито Выступит На .Next В Москве
19 Oct, 24 -
Практика Удаленной Работы: Взгляд Изнутри
19 Oct, 24 -
Установка Сетевой Версии 1С 7.7 На Linux
19 Oct, 24 -
Вся Правда Об Apple
19 Oct, 24
