Структура проектов на C++ с использованием Subversion и Mxx_ - Средства разработки

Отрывок из статьи :

Такая организация исходных текстов позволяет задавать свойство svn:externals для корневого каталога проекта — для каталога dev. Так, для dev/ из oess_1.4.0-b1 свойство svn:externals имеет значение:

args_4 http://svn.intervale.ru/svn/args_4/tags/4.4/dev/args_4
auto_ptr_3 http://svn.intervale.ru/svn/auto_ptr_3/tags/3.2/dev/auto_ptr_3
cls_2 http://svn.intervale.ru/svn/cls_2/tags/2.7/dev/cls_2
cpp_util_2 http://svn.intervale.ru/svn/cpp_util_2/tags/2.2/dev/cpp_util_2
smart_ref_3 http://svn.intervale.ru/svn/smart_ref_3/tags/3.1/dev/smart_ref_3
threads_1 http://svn.intervale.ru/svn/threads_1/tags/1.4/dev/threads_1
ace http://svn.intervale.ru/svn/ace/tags/5.4.3/dev/ace
pcre http://svn.intervale.ru/svn/pcre/tags/4.5/dev/pcre
libpcre++ http://svn.intervale.ru/svn/libpcre++/tags/0.9/dev/libpcre++

Такое значение свойства svn:externals предписывает Subversion взять, например, содержимое каталога ace из репозитория svn.intervale.ru/svn/ace, причем из ветви tags/5.4.3. При выполнении операций check out и export Subversion автоматически возьмет оттуда содержимое каталога ace.

Важно отметить, что при выполнении операции check out Subversion создает для подпроекта рабочую копию в подкаталоге, указанном в svn:externals. Так, после выполнения check out для oess_1.4.0-b1, каталог dev/ace будет представлять собой рабочую копию для ветви tags/5.4.3/dev/ace из репозитория svn.intervale.ru/svn/ace. Но при этом рабочая копия подпроекта ace располагается внутри рабочей копии проекта oess_1, как будто исходные тексты ACE были импортированы в репозиторий oess_1.

То, что для каждого подпроекта, подключенного через svn:externals, при выполнении check out создается рабочая копия, приводит к двум важным следствиям:

1. При обнаружении какой-либо ошибки в подпроекте ее можно здесь же исправить и сохранить изменения в репозиторий подпроекта.
2. При выполнении операции update Subversion выполнит автоматический update всех подключенных через svn:externals подпроектов. Поэтому, если в репозиторий какого-то подпроекта были внесены какие-то изменения, то они автоматически будут отражены в рабочем каталоге этого подпроекта после update.

Не согласен, checkout из tags помоему не совсем корректная операция. checkout подразумевает что будет делаться checkin, т.е. изменения будут коммититься прямо в tags.
Допустим зафиксирована версия компонента ace 5.4.3 , мы можем всегда забрать из tags/5.4.3 исходный текст компонента и понять почему у заказчика N , с данной версией определенные проблемы. Но если мы будем туда коммититься вносить изменения, то будет версия компонента одна , а реализация разная — полный бардак.
Если что-то поменялось — это должна быть новая версия , новый tags\5.4.4 и т.п.

Здравствуйте, <Аноним>, Вы писали:

А>Не согласен, checkout из tags помоему не совсем корректная операция. checkout подразумевает что будет делаться checkin, т.е. изменения будут коммититься прямо в tags.

Это как раз достоинство, т.к. и в tags иногда находятся баги. Особенно, если ты сам занимаешься разработкой нескольких проектов и в одном из них сам находишь баг. Ведь никто, кроме тебя его не поправит.

Кроме того, часто commit запрещается, т.к. разработчик, который берет tags из чужого проекта, имеет право только делать checkout из tags (т.е. read-only доступ к чужому репозиторию).

А>Допустим зафиксирована версия компонента ace 5.4.3 , мы можем всегда забрать из tags/5.4.3 исходный текст компонента и понять почему у заказчика N , с данной версией определенные проблемы. Но если мы будем туда коммититься вносить изменения, то будет версия компонента одна , а реализация разная — полный бардак.
А>Если что-то поменялось — это должна быть новая версия , новый tags\5.4.4 и т.п.

Указанная тобой проблема решается указанием в svn:externals точной ревизии через опцию -r. См. так же: Re: Хранение сложных проектов в репозитории и установка tag’

Поэтому, если ты отдаешь какую-то версию софта заказчику, то имеет смысл сделать для этой версии отдельный tag, в котором в svn:externals точно фиксируются ревизии всех использованных проектов.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

А>>Не согласен, checkout из tags помоему не совсем корректная операция. checkout подразумевает что будет делаться checkin, т.е. изменения будут коммититься прямо в tags.

E>Это как раз достоинство, т.к. и в tags иногда находятся баги. Особенно, если ты сам занимаешься разработкой нескольких проектов и в одном из них сам находишь баг. Ведь никто, кроме тебя его не поправит.

Подождите, tags — по определению это ветка в которой фиксируются версии, если есть tags/5.3.4 и в ней будут ошибки значит версия компонента 5.3.4 имеет ошибки. И исправлять их будьте добры в branch/5.3.4 в который вы скопируете tags/5.3.4 после исправления ошибок в branches\5.3.4 делается копия в tags/5.3.5 и выпускается новый компонент версии 5.3.5 с исправленными ошибками.

Но в tags/5.3.4 он должен остаться таким какой он есть, плохим или хорошим, иначе смысл tags/ и branches/ пропадает.

Здравствуйте, <Аноним>, Вы писали:

Ну, во-первых, я не понимаю, из-за чего сыр-бор. Хотите, чтобы нельзя было в tags делать checkin -- да ради бога, есть два надежных способа:
a) указывать в svn:externals точные ревизии;
b) дать пользователю read-only доступ к ветке tags.

Ну и, во-вторых,

А>Подождите, tags — по определению это ветка в которой фиксируются версии, если есть tags/5.3.4 и в ней будут ошибки значит версия компонента 5.3.4 имеет ошибки. И исправлять их будьте добры в branch/5.3.4 в который вы скопируете tags/5.3.4 после исправления ошибок в branches\5.3.4 делается копия в tags/5.3.5 и выпускается новый компонент версии 5.3.5 с исправленными ошибками.

Все зависит от степени тяжести бага и дисциплины работы. Например, прислали мне сегодня файл, в котором было:

#include <iostream>
#include <cmath>
#include <time.h>
...

и мне компилятор выдал ошибку, что оператор сдвига std::string в std::ostream не определен. Ну пользовался человек другим компилятором, бывает такое. Ошибка лечится элементарно -- добавлением еще одного include. И я думаю, что такое исправление вполне можно закомитить обратно в tags без промежуточных branches и выделения новой версии.

Кроме того, у меня svn по умолчанию версии из svn:externals не коммитит. Поэтому, если я даже что-то в своем рабочем каталоге в чужом проекте подправил, то просто так эти изменения обратно не попадут.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Все зависит от степени тяжести бага и дисциплины работы. Например, прислали мне сегодня файл, в котором было:
E>

E>#include <iostream>
E>#include <cmath>
E>#include <time.h>
E>...
E>

E>и мне компилятор выдал ошибку, что оператор сдвига std::string в std::ostream не определен. Ну пользовался человек другим компилятором, бывает такое. Ошибка лечится элементарно -- добавлением еще одного include. И я думаю, что такое исправление вполне можно закомитить обратно в tags без промежуточных branches и выделения новой версии.

Грубое нарушение основных принципов CM.
На то он и выпуск версий (не важно каких),
чтобы их содержимое не менять.

Сдвиги релизных меток имеют смысл только если они просто фиксируют
ошибочную версию файла. Т.е. просто по ошибки не туда навесили.
Иначе ни в коем случае.

Здравствуйте, <Аноним>, Вы писали:

А>Грубое нарушение основных принципов CM.
А>На то он и выпуск версий (не важно каких),
А>чтобы их содержимое не менять.

Да ради бога. Видимо, тебе так проще. Мне удобнее то, что я описал в статье.

А>Сдвиги релизных меток имеют смысл только если они просто фиксируют
А>ошибочную версию файла. Т.е. просто по ошибки не туда навесили.
А>Иначе ни в коем случае.

Вообще наш спор напоминает спор приверженцев статически и динамически типизированных языков. Апологеты статической типизации любят говорить, что т.к. компилятор не отлавливает даже синтаксические ошибки, то в программе полно багов. Опоненты отвечают -- на самом деле синтаксических ошибок и ошибок типизации совсем не так много и подавляющее их число отлавливается unit-тестами. Т.е. формализм (статическая типизация во время компиляции) уcпешно заменяется дисциплиной (unit-тестами).

Так же и здесь. Твой формализм говорит, что после выпуска tag-а, в нем ничего нельзя менять. Иначе ничему нельзя доверять, все плывет, и вообще "вся библия нафиг" ((С) Оба-на). Это формальная точка зрения.
Я придерживаюсь другого мнения -- чтобы получать те же самые результаты нужно придерживаться дисциплины. Например, при выпуске релиза для заказчика обязательно нужно указать в svn:externals точные ревизии используемых подпроектов. И не коммитить изменения в tags чужого проекта, если на то нет очень серьезных оснований.

И такой дисциплинированный подход не показал пока никаких проблем. Никаких. Так что я не вижу причин от него отказываться из-за формально-религиозных возрений. К тому же альтернатив все равно озвучено не было. А бенефиты в моем подходе есть серьезные. Например, автоматическое получение при update обновленных версий использованных подпроектов. Без необходимости изменять svn:externals. Скажем, зачем мне менять вручную ссылку на oess_1/tags/1.4.0 на oess_1/tags/1.4.1, если версия 1.4.1 (в своем номере) гарантирует полную совместимость с 1.4.0? Если мне не нужна конкретно 1.4.0, то я бы с удовольствием перешел на 1.4.1 так только последняя бы появилась в наличии. Мой подход это позволяет сделать, т.к. в большинстве проектов в tags указывается двухразрядные номера (oess_1/tags/1.4 вместо oess_1/tags/1.4.0 и oess_1/tags/1.4.1). А приведенный в статье пример с ace/tags/5.4.3 -- это частный случай, т.к. ACE -- это не моя разработка и я не могу управлять нумерацией их версий, какая была последняя в наличии, для такой и был сделан tag в репозитории.

А вот если мне нужна именно 1.4.0, то я могу в svn:externals указать ветку oess_1/tags/1.4, но задать точную ревизию. И все! Даже если в oess_1/tags/1.4 будет со временем содержаться версия 1.4.25748, то я все равно буду использовать 1.4.0.

Вот и получается, что мой подход позволяет сочетать как строгость (использование точных номеров ревизий + предоставление только read-only доступа к репозиториям), так и простоту (автоматическое получение изменений при checkout и update). И все это уже не первый год реально работает. А в качестве возражения мне приводится формальный довод о том, что после выделения tag-а, изменять его нельзя.

В конце-концов, я ведь не навязываю всем свой подход, как единственно правильный. Не нравится, не используй.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

А>>Грубое нарушение основных принципов CM.
А>>На то он и выпуск версий (не важно каких),
А>>чтобы их содержимое не менять.

E>Да ради бога. Видимо, тебе так проще. Мне удобнее то, что я описал в статье.

Мне (и не только мне) и в самом деле так проще.
Думать не надо совершенно и просто тупо вешается новая метка
по совершенно четким правилам. Чего их жалеть, метки?
А вот причины, по которым сдвигают метки, могут быть довольно сомнительными.

У тебя еще не было ситуаций, когда 2 человека обсуждают
две реально разные версии файла (документа и пр...) пребывая
в твердой уверенности, что это одно и то же?

E>В конце-концов, я ведь не навязываю всем свой подход, как единственно правильный. Не нравится, не используй.

Я и не использую и тоже ни к чему не призываю.
Просто комментирую. Или тебе комментарии не нужны?

Здравствуйте, <Аноним>, Вы писали:

А>У тебя еще не было ситуаций, когда 2 человека обсуждают
А>две реально разные версии файла (документа и пр...) пребывая
А>в твердой уверенности, что это одно и то же?

Нет. А как это возможно, если используется система контроля версий?

E>>В конце-концов, я ведь не навязываю всем свой подход, как единственно правильный. Не нравится, не используй.

А>Я и не использую и тоже ни к чему не призываю.
А>Просто комментирую. Или тебе комментарии не нужны?

Нужны. И твой комментарий, возможно, окажется полезным кому-то из читателей статьи. А я просто с ним не согласен.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

А>>У тебя еще не было ситуаций, когда 2 человека обсуждают
А>>две реально разные версии файла (документа и пр...) пребывая
А>>в твердой уверенности, что это одно и то же?

E>Нет. А как это возможно, если используется система контроля версий?

При сдвиге меток возможно.

Здравствуйте, <Аноним>, Вы писали:

А>>>У тебя еще не было ситуаций, когда 2 человека обсуждают
А>>>две реально разные версии файла (документа и пр...) пребывая
А>>>в твердой уверенности, что это одно и то же?

E>>Нет. А как это возможно, если используется система контроля версий?

А>При сдвиге меток возможно.

Не уверен, что понимаю термин "сдвиг меток". Можно ли раскрыть его смысл?

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

А>>>>У тебя еще не было ситуаций, когда 2 человека обсуждают
А>>>>две реально разные версии файла (документа и пр...) пребывая
А>>>>в твердой уверенности, что это одно и то же?

E>>>Нет. А как это возможно, если используется система контроля версий?

А>>При сдвиге меток возможно.

E>Не уверен, что понимаю термин "сдвиг меток". Можно ли раскрыть его смысл?

Это когда в 2 разных момента времени, элементы,
помеченные одной меткой, отличаются друг от друга.
Как это физически реализуется в разных системах контроля версий — это уже детали.
Мы вроде об этом говорим?

Здравствуйте, <Аноним>, Вы писали:

E>>Не уверен, что понимаю термин "сдвиг меток". Можно ли раскрыть его смысл?

А>Это когда в 2 разных момента времени, элементы,
А>помеченные одной меткой, отличаются друг от друга.
А>Как это физически реализуется в разных системах контроля версий — это уже детали.
А>Мы вроде об этом говорим?

Я, кажется, начинаю понимать, о чем ты говоришь.
Только дело в том, что в Subversion имя tag -- это не есть "точная" отметка. Ты правильно заметил, что после выделения tag с ним еще много чего может происходить. В него могут коммитить изменения, его могут переименовать, на его место могут создать новый tag c таким же именем. Поэтому имя tag-а -- это всего лишь отражение логической структуры репозитория.

А есть в Subversion точная отметка состояния -- номер ревизии. Поэтому, скажем, oess_1/tags/1.4:435 -- это точное состояние тега 1.4 на ревизии 435. И элементы, которые входили в oess_1/tags/1.4 на этой ревизии уже не могут различаться ни в какие моменты времени. (если конечно с самим репозиторием на низком уровне не пошаманить).

Вот поэтому я и считаю свой подход вполне удобным, т.к., если нам нужно избежать "сдвига меток", то это легко достигается указанием в свойстве svn:externals номера ревизии:

oess_1 -r 435 http://svn.intervale.ru/svn/oess_1/tags/1.4

Все. После этого я не могу ни закоммитить изменения в oess_1, ни получить изменения, которые в него внесли после ревизии 435. При выделении версий ПО, которые передаются заказчику или запускаются в эксплуатацию, мы именно так и фиксируем точное состояние проекта.

... << RSDN@Home 1.1.4 stable rev. 510>>

В общем довольно разумно.
Спасибо за разъяснение!

Здравствуйте, <Аноним>, Вы писали:

А>В общем довольно разумно.

Вот и мне так же показалось, поэтому решил в статье этот опыт и описать.

А>Спасибо за разъяснение!

Да завсегда пожалуйста

Спасибо за проявленный интерес.

... << RSDN@Home 1.1.4 stable rev. 510>>

А ты с svn:externals разобрался? Вообще в доках не нашёл синтаксиса данной команды, императивно выяснил что под винды работает след. конструкция:

svn propset svn:externals "trunk/3DPart/M2 svn://localhost/MyCoolExternal" .

А вот как выставить несколько экстерналов — непонятно, спасает пока тортилка, там есть гуй а с ним — проще

Здравствуйте, Tom, Вы писали:

Tom>А ты с svn:externals разобрался? Вообще в доках не нашёл синтаксиса данной команды, императивно выяснил что под винды работает след. конструкция:
Tom>

Tom>svn propset svn:externals "trunk/3DPart/M2 svn://localhost/MyCoolExternal" .
Tom>

Tom>А вот как выставить несколько экстерналов — непонятно, спасает пока тортилка, там есть гуй а с ним — проще

Одна строка — один external.
Используйте svn propedit.

А в доках это здесь: http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-3

Здравствуйте, Tom, Вы писали:

Tom>А ты с svn:externals разобрался?

А там ничего сложного, имхо. К тому же, я работаю через файлы с svn:externals. Например, нужно на каталог dev установить свойство svn:externals. Формирую текстовый файл svn_externals.log со всеми нужными значениями, затем выдаю команду:

svn ps svn:externals dev -F svn_externals.log

Затем можно сразу дать "svn up" и проверить, правильно ли все получилось. Если не правильно, еще раз исправляем svn:externals и повторяем. После окончательных изменений коммитим.

Если нужно взять текущие свойства для dev и изменить их, то опять пользуюсь текстовым файлом:

svn pg svn:externals dev > svn_externals.log

Затем файл svn_externals.log правится и проделываются уже известные шаги.

Tom>А вот как выставить несколько экстерналов — непонятно, спасает пока тортилка, там есть гуй а с ним — проще

А по мне, так через текстовый файл проще.

Здравствуйте, eao197, Вы писали:

В общем объясняю минус.

Твою философию в этом вопросе я понял, но с ней не согласен. Всё же предпочитаю придерживаться формальных правил совместной разработки.

Branch — ветка, в которой допустимы изменения, часть из которых будет слита с основной разработкой. За бранчем требуется следить: обновление внешних библиотек, мердж с основной разработкой, исправление багов, внесение доп. возможностей и т.п.

Tag — закреплённое состояние некоторых исходников, в общем-то просто синоним некоторой ревизии для SVN (в других системах это ессно не так). Используется для идентификации состояния исходников в других системах аля bugtracking, testing, integration и т.п. Чем хорош этот синоним — тем, что он собственно может использоваться и без SVN и находится где угодно и при этом его состояние в любой момент будет таким же как и в SVN (Будь это zip архив или даже Version Сontrol другой системы). Следить за тагом не требуется, ведь он никогда не изменяется.

И чем удобен таг, что можно всегда сказать, что в таге "first integration" были обнаружены такие-то ошибки, добавлены такие-то фичи и т.д., а не в 1047 ревизии этого тага "first integration", хотя стоп, может ревизия была 1407

... полез смотреть логи

.

C Уважением, Andir!

... << RSDN@Home 1.2.0 alpha rev. 631>>

От:	Евгений Охотников	http://eao197.blogspot.com
Дата:	23.05.05 11:11
Оценка:	375 (8) +1 -1

От:	eao197	http://eao197.blogspot.com
Дата:	11.11.05 14:48
Оценка:

	От:	Аноним
	Дата:	25.11.05 08:45
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	25.11.05 09:05
Оценка:

	От:	Аноним
	Дата:	25.11.05 14:01
	Оценка:	+1

От:	Tom	http://www.RSDN.ru
Дата:	16.01.06 20:39
Оценка:

От:	Andir	http://twitter.com/AndirNotes
Дата:	19.01.06 06:04
Оценка:	10 (1)

	От:	Elifant
	Дата:	17.01.06 04:08
	Оценка: