Когда вышла версия SVN 1.5, помню, мы с коллегами очень обрадовались долгожданной поддержке записи истории переноса изменений (merge), которую до тех пор мы вели в комментариях к правкам и это, конечно, очень нас напрягало. На радостях нам в голову начали приходить различные идеи, как можно использовать эту новую возможность, и однажды мы решили реализовать с ее помощью модульность на уровне исходного кода.
Идея заключалась в том, чтобы не делать отдельные библиотеки подключаемые во время выполнения, как это это обычно делается, а выделить повторно используемую в разных проектах функциональность в отдельные ветки и переносить их на новый проект при необходимости.
Мы взяли основную ветку платформы, ответвили от нее штук 5 модульных веток, в каждую из которых добавили функциональность одного отдельного модуля и поддерживали их актуальность перенося на них изменения со ствола.
Все шло хорошо. Когда нам нужно было собрать дистрибутив включающий несколько конкретных модулей, мы ответвляли новый проект от ствола и последовательно переносили на него изменения с веток нужных модулей.
Но в процессе разработки конкретных проектов, мы столкнулись с необходимостью доработок и исправлений в их коде, причем, как основного кода ствола, так и кода наших псевдо-модулей. Естественно, эти полезные изменения нужно было переносить обратно на ствол и ветки модулей, чтобы они попали в будущие проекты, что мы и делали.
И тут мы столкнулись с неожиданным для нас эффектом. SVN хранит историю перенесенных на ветку изменений в обычном текстовом свойстве корневой папки. Текст свойства — это перечень веток, с которых когда-либо переносились изменения на данную, с указанием, какие именно ревизии были перенесены.
Так вот, главная в нашем случае особенность реализации механизма смешивания в SVN заключается в том, что при любом переносе любых изменений, даже какой-то одной небольшой правки с одной ветки на другую, вместе с этой правкой также полностью переносится ВСЯ merge-история.
И вот что произошло у нас. При переносе изменений на ствол с проектов, содержащих в себе модули, на ствол также попадали и записи об интеграции этих модулей. И все следующие ответвленные от ствола проекты уже отказывались принимать код модулей считая, что уже получили эти изменения ранее.
И мы поняли, что SVN обладает одним важным в нашем случае ограничением, смысл которого можно описать так: нельзя, чтобы в путях переноса изменений образовывались замкнутые контуры.
Мы попытались оптимизировать эти пути, придумывая различные правила, мы разделили изменения на классы и установили отдельные правила для каждого из них, но в итоге поняли, что все это слишком сложно и неудобно, и отказались от так понравившейся нам идеи модульности на уровне исходников, заменив ее обычной run-time модульностью.
В последнее время я все чаще слышу восторженные отзывы от моих знакомых о распределенных системах управления версиями, в частности Mercurial и Git. И у меня возник вопрос, а можно ли на этих системах организовать такую сложную схему переноса изменений?
Прошу людей, использующих упомянутые или другие системы, рассказать, можно ли в них переносить изменения по замкнутым контурам без возникновения описанной проблемы? Например, на следующей схеме можно ли будет сделать merge-правку 8? И заблокирует ли система попытку повторного переноса 9?
SVN, например, заблокирует обе.
UP: tzlom говорит, что Git позволит сделать обе правки, и, естественно, в 9-ой создаст коллизию. В общем-то, в SVN тоже можно игнорировать блокировки, и тогда эффект будет такой же.
UP: PQR подсказал, что в Mercurial правки можно атомарно переносить с помощью расширения Transplant, а в Git с помощью команды cherry-pick, но, судя по всему, в обоих случаях будут разрешены обе правки (8 и 9).
Идея заключалась в том, чтобы не делать отдельные библиотеки подключаемые во время выполнения, как это это обычно делается, а выделить повторно используемую в разных проектах функциональность в отдельные ветки и переносить их на новый проект при необходимости.
Мы взяли основную ветку платформы, ответвили от нее штук 5 модульных веток, в каждую из которых добавили функциональность одного отдельного модуля и поддерживали их актуальность перенося на них изменения со ствола.
Все шло хорошо. Когда нам нужно было собрать дистрибутив включающий несколько конкретных модулей, мы ответвляли новый проект от ствола и последовательно переносили на него изменения с веток нужных модулей.
Но в процессе разработки конкретных проектов, мы столкнулись с необходимостью доработок и исправлений в их коде, причем, как основного кода ствола, так и кода наших псевдо-модулей. Естественно, эти полезные изменения нужно было переносить обратно на ствол и ветки модулей, чтобы они попали в будущие проекты, что мы и делали.
И тут мы столкнулись с неожиданным для нас эффектом. SVN хранит историю перенесенных на ветку изменений в обычном текстовом свойстве корневой папки. Текст свойства — это перечень веток, с которых когда-либо переносились изменения на данную, с указанием, какие именно ревизии были перенесены.
Так вот, главная в нашем случае особенность реализации механизма смешивания в SVN заключается в том, что при любом переносе любых изменений, даже какой-то одной небольшой правки с одной ветки на другую, вместе с этой правкой также полностью переносится ВСЯ merge-история.
И вот что произошло у нас. При переносе изменений на ствол с проектов, содержащих в себе модули, на ствол также попадали и записи об интеграции этих модулей. И все следующие ответвленные от ствола проекты уже отказывались принимать код модулей считая, что уже получили эти изменения ранее.
И мы поняли, что SVN обладает одним важным в нашем случае ограничением, смысл которого можно описать так: нельзя, чтобы в путях переноса изменений образовывались замкнутые контуры.
Мы попытались оптимизировать эти пути, придумывая различные правила, мы разделили изменения на классы и установили отдельные правила для каждого из них, но в итоге поняли, что все это слишком сложно и неудобно, и отказались от так понравившейся нам идеи модульности на уровне исходников, заменив ее обычной run-time модульностью.
В последнее время я все чаще слышу восторженные отзывы от моих знакомых о распределенных системах управления версиями, в частности Mercurial и Git. И у меня возник вопрос, а можно ли на этих системах организовать такую сложную схему переноса изменений?
Прошу людей, использующих упомянутые или другие системы, рассказать, можно ли в них переносить изменения по замкнутым контурам без возникновения описанной проблемы? Например, на следующей схеме можно ли будет сделать merge-правку 8? И заблокирует ли система попытку повторного переноса 9?
SVN, например, заблокирует обе.
UP: tzlom говорит, что Git позволит сделать обе правки, и, естественно, в 9-ой создаст коллизию. В общем-то, в SVN тоже можно игнорировать блокировки, и тогда эффект будет такой же.
UP: PQR подсказал, что в Mercurial правки можно атомарно переносить с помощью расширения Transplant, а в Git с помощью команды cherry-pick, но, судя по всему, в обоих случаях будут разрешены обе правки (8 и 9).
