Аннотация:
Данная статья описывает предложения по организации файловой структуры проектов на C++ и компиляции проектов с помощью Mxx_ru (http://eao197.narod.ru/mxx_ru), а так же показывает, как использовать систему контроля версий Subversion (http://subversion.tigris.org) не только в качестве инструмента для управления версиями исходных текстов, но и для отслеживания зависимостей между проектами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Структура проектов на C++ с использованием Subversion и
To mozi: а минус за что? Что-то конкретное не понравилось или это общее впечатление от статьи?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Структура проектов на C++ с использованием Subversion и
От:
Аноним
Дата:
25.11.05 08:45
Оценка:
Отрывок из статьи :
Такая организация исходных текстов позволяет задавать свойство svn:externals для корневого каталога проекта — для каталога dev. Так, для dev/ из oess_1.4.0-b1 свойство svn:externals имеет значение:
Такое значение свойства 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 и т.п.
Re[2]: Структура проектов на C++ с использованием Subversion
Здравствуйте, <Аноним>, Вы писали:
А>Не согласен, 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 и т.п.
Поэтому, если ты отдаешь какую-то версию софта заказчику, то имеет смысл сделать для этой версии отдельный tag, в котором в svn:externals точно фиксируются ревизии всех использованных проектов.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Структура проектов на C++ с использованием Subversion
Здравствуйте, 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/ пропадает.
Re[4]: Структура проектов на C++ с использованием Subversion
Ну, во-первых, я не понимаю, из-за чего сыр-бор. Хотите, чтобы нельзя было в 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 с исправленными ошибками.
Все зависит от степени тяжести бага и дисциплины работы. Например, прислали мне сегодня файл, в котором было:
и мне компилятор выдал ошибку, что оператор сдвига std::string в std::ostream не определен. Ну пользовался человек другим компилятором, бывает такое. Ошибка лечится элементарно -- добавлением еще одного include. И я думаю, что такое исправление вполне можно закомитить обратно в tags без промежуточных branches и выделения новой версии.
Кроме того, у меня svn по умолчанию версии из svn:externals не коммитит. Поэтому, если я даже что-то в своем рабочем каталоге в чужом проекте подправил, то просто так эти изменения обратно не попадут.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Структура проектов на C++ с использованием Subversion
E>и мне компилятор выдал ошибку, что оператор сдвига std::string в std::ostream не определен. Ну пользовался человек другим компилятором, бывает такое. Ошибка лечится элементарно -- добавлением еще одного include. И я думаю, что такое исправление вполне можно закомитить обратно в tags без промежуточных branches и выделения новой версии.
Грубое нарушение основных принципов CM.
На то он и выпуск версий (не важно каких),
чтобы их содержимое не менять.
Сдвиги релизных меток имеют смысл только если они просто фиксируют
ошибочную версию файла. Т.е. просто по ошибки не туда навесили.
Иначе ни в коем случае.
Re[6]: Структура проектов на C++ с использованием Subversion
Здравствуйте, <Аноним>, Вы писали:
А>Грубое нарушение основных принципов 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>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Структура проектов на C++ с использованием Subversion
От:
Аноним
Дата:
26.11.05 10:48
Оценка:
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, <Аноним>, Вы писали:
А>>Грубое нарушение основных принципов CM. А>>На то он и выпуск версий (не важно каких), А>>чтобы их содержимое не менять.
E>Да ради бога. Видимо, тебе так проще. Мне удобнее то, что я описал в статье.
Мне (и не только мне) и в самом деле так проще.
Думать не надо совершенно и просто тупо вешается новая метка
по совершенно четким правилам. Чего их жалеть, метки?
А вот причины, по которым сдвигают метки, могут быть довольно сомнительными.
У тебя еще не было ситуаций, когда 2 человека обсуждают
две реально разные версии файла (документа и пр...) пребывая
в твердой уверенности, что это одно и то же?
E>В конце-концов, я ведь не навязываю всем свой подход, как единственно правильный. Не нравится, не используй.
Я и не использую и тоже ни к чему не призываю.
Просто комментирую. Или тебе комментарии не нужны?
Re[8]: Структура проектов на C++ с использованием Subversion
Здравствуйте, <Аноним>, Вы писали:
А>У тебя еще не было ситуаций, когда 2 человека обсуждают А>две реально разные версии файла (документа и пр...) пребывая А>в твердой уверенности, что это одно и то же?
Нет. А как это возможно, если используется система контроля версий?
E>>В конце-концов, я ведь не навязываю всем свой подход, как единственно правильный. Не нравится, не используй.
А>Я и не использую и тоже ни к чему не призываю. А>Просто комментирую. Или тебе комментарии не нужны?
Нужны. И твой комментарий, возможно, окажется полезным кому-то из читателей статьи. А я просто с ним не согласен.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Структура проектов на C++ с использованием Subversion
От:
Аноним
Дата:
26.11.05 13:57
Оценка:
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, <Аноним>, Вы писали:
А>>У тебя еще не было ситуаций, когда 2 человека обсуждают А>>две реально разные версии файла (документа и пр...) пребывая А>>в твердой уверенности, что это одно и то же?
E>Нет. А как это возможно, если используется система контроля версий?
При сдвиге меток возможно.
Re[10]: Структура проектов на C++ с использованием Subversio
Здравствуйте, <Аноним>, Вы писали:
А>>>У тебя еще не было ситуаций, когда 2 человека обсуждают А>>>две реально разные версии файла (документа и пр...) пребывая А>>>в твердой уверенности, что это одно и то же?
E>>Нет. А как это возможно, если используется система контроля версий?
А>При сдвиге меток возможно.
Не уверен, что понимаю термин "сдвиг меток". Можно ли раскрыть его смысл?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Структура проектов на C++ с использованием Subversio
От:
Аноним
Дата:
26.11.05 14:12
Оценка:
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, <Аноним>, Вы писали:
А>>>>У тебя еще не было ситуаций, когда 2 человека обсуждают А>>>>две реально разные версии файла (документа и пр...) пребывая А>>>>в твердой уверенности, что это одно и то же?
E>>>Нет. А как это возможно, если используется система контроля версий?
А>>При сдвиге меток возможно.
E>Не уверен, что понимаю термин "сдвиг меток". Можно ли раскрыть его смысл?
Это когда в 2 разных момента времени, элементы,
помеченные одной меткой, отличаются друг от друга.
Как это физически реализуется в разных системах контроля версий — это уже детали.
Мы вроде об этом говорим?
Re[12]: Структура проектов на C++ с использованием Subversio
Здравствуйте, <Аноним>, Вы писали:
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, ни получить изменения, которые в него внесли после ревизии 435. При выделении версий ПО, которые передаются заказчику или запускаются в эксплуатацию, мы именно так и фиксируем точное состояние проекта.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Структура проектов на C++ с использованием Subversio
От:
Аноним
Дата:
26.11.05 14:41
Оценка:
В общем довольно разумно.
Спасибо за разъяснение!
Re[14]: Структура проектов на C++ с использованием Subversio
Здравствуйте, Tom, Вы писали:
Tom>А ты с svn:externals разобрался? Вообще в доках не нашёл синтаксиса данной команды, императивно выяснил что под винды работает след. конструкция: Tom>
Здравствуйте, 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>А вот как выставить несколько экстерналов — непонятно, спасает пока тортилка, там есть гуй а с ним — проще
А по мне, так через текстовый файл проще.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Структура проектов на C++ с использованием Subversion
Твою философию в этом вопросе я понял, но с ней не согласен. Всё же предпочитаю придерживаться формальных правил совместной разработки.
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>>
Re[8]: Структура проектов на C++ с использованием Subversion
Здравствуйте, Andir, Вы писали:
A>Tag — закреплённое состояние некоторых исходников, в общем-то просто синоним некоторой ревизии для SVN (в других системах это ессно не так). Используется для идентификации состояния исходников в других системах аля bugtracking, testing, integration и т.п. Чем хорош этот синоним — тем, что он собственно может использоваться и без SVN и находится где угодно и при этом его состояние в любой момент будет таким же как и в SVN (Будь это zip архив или даже Version Сontrol другой системы). Следить за тагом не требуется, ведь он никогда не изменяется.
Понятно. Но скажи, ведь выделение tag не означает фиксацию абсолютно безошибочной версии. Обязательно будут находится ошибки, которые будут исправляться в branch-ах и куда-то затем должны помещаться. Т.е. выделяем tags/1.0.0. Правим первый баг, делаем новый tags/1.0.1. Затем исправляем следующий, получаем tags/1.0.2, и т.д. Допустим, исправляем пять багов и получаем пять тегов 1.0.<N> в tags. Это только для одного проекта. Правильно ли я понимаю, что ты предлагаешь (предпочитаешь) этот путь?
Теперь представим, что мы исправляли ошибки в подпроекте (например, oess_1), который, в свою очередь входит в подпроект so_4, который в свою очередь входит в подпроект aag_3. Итак, есть oess_1/tags/1.0.0, oess_1/tags/1.0.1 и т.д., oess_1/tags/1.0.5. Есть so_4/tags/4.3.2, который был построен на oess_1/tags/1.0.0. Что нужно сделать с so_4, чтобы перейти на oess_1/tags/1.0.5? Просто сменить externals в so_4/tags/4.3.2 или же создать новый тег so_4/tags/4.3.3? Наверное, создать новый тег, т.к. не факт, что исправление ошибки в oess_1/tags/1.0.5 не выявило какую-то скрытую ошибку в so_4. Итого, получается, что как только мы выделяем новый тег с bugfix-ом в подпроекте so_4, мы должны делать новый тег в so_4. Если so_4 зависит не только от oess_1, а еще от четырех подпроектов, то новый тег в so_4 будет создаваться при появлении нового тега в любом из подпроектов. И то же самое будет происходить в aag_3. Т.е. исправление на самом нижнем уровне пирамиды взаимосвязей проектов будет приводить к каскадному росту числа тегов к вершине пирамиды.
Так это представляется мне. Или же ты пользуешься какой-то другой схемой?
А впечатление от самой статьи есть какие-нибудь?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Структура проектов на C++ с использованием Subversion и
Я в статье описываю идею добавления в имя верхнего пространства имен номера версии (т.е. oess_1, so_4, smart_ref_3 и т.д.). Но нигде больше подобных вещей не видел. До недавнего времени. В мартовском выпуске "ACE News and Tips Newsletter" говорится буквально следующее:
ACE's popularity is growing by the day it seems, and with the increased popularity, it's becoming more common for multiple applications on a system to require ACE. This can cause problems because:
* Different ACE releases can have API differences
* Rebuilding ACE with a different compiler version can change the name mangling
* Some applications may require different features or settings than others
Prior to ACE 5.5, these issues often forced developers to build and use ACE as a statically linked library or to take some other nonstandard approach to isolating the needed version of ACE.
Beginning with ACE 5.5, there is a new feature designed to help alleviate these difficulties. The ACE Namespace Versioning provides a means for ACE-based application developers to avoid symbol conflicts by using versioned namespaces. This is an optional feature and its default setting is off (disabled) equivalent to all prior versions of ACE. When enabled, ACE's versioned namespace support causes all ACE symbols (classes, free functions, etc.) to be placed within a C++ namespace of the form namespace ACE_<ACE-version>. For example, at ACE 5.5, the default namespace name is ACE_5_5_0. The ACE_Reactor would end up being placed in the versioned namespace like this:
namespace ACE_5_5_0
{
class ACE_Reactor
{
...
};
}
using namespace ACE_5_5_0;
Вот, теперь и они додумались
Только трехзначный номер версии в имени пространства имен -- это уже перебор, имхо. Слишком много геморроя будет при переходе, скажем, с ACE_5_5_0 на ACE_5_5_1, т.к. обычно версии с изменением третьей цифры являются всего лишь bug-fix версиями.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Структура проектов на C++ с использованием Subversion
E>Я в статье описываю идею добавления в имя верхнего пространства имен номера версии (т.е. oess_1, so_4, smart_ref_3 и т.д.). Но нигде больше подобных вещей не видел. До недавнего времени.
Я вообще-то не удивлён, что такие пространства имён не используются, потому как это скорее напоминает заплатку для версионности АПИ, чем для реального разделения по пространствам имён (как я понимаю делается это для того, чтобы избавится от несовместимостей АПИ в разных версиях библиотеки), какие проблемы будет решать такая конвенция наименования? .
1) В COM помнится я видел уже подобное аля IClassFactory2, IProvideClassInfo2, INavigate2 и т.п. не сказал бы что это мне понравилось, скорее даже наоборот. При этом тут, кстати, всё намного лучше, то есть пока не реализован новый интерфейс, то объекты пользуются старым, а здесь же простая смена пространства имён может приводить к гораздо более существенным проблемам с несовместимостью внутреннего АПИ.
2) При переходе с одной версии на другую, что предполагается делать? Есть ли вариант, что somenamespace_1::MyAPIFunction будет отличаться от somenamespace_2::MyAPIFunction порядком параметров, типом параметров, типом результата и т.п. (выбрасываемыми исключениями например ).
3) Что произойдёт если я просто поменяю using namespace somenamespace_1 на using namespace somenamespace_2, могут ли при этом возникать ошибки логического плана, которые не так просто отследить в большом проекте?
Больше всего в такой конвенции меня смущает именно последняя проблема, ошибки компиляции легко определятся компилятором, но вот маскировка несовместимости в логике вызова АПИ пространством имён ...
Продолжаем разговор, извиняюсь, но в дело вмешался случай и я видно не отправил ответ в прошлый раз.
A>>Tag — закреплённое состояние некоторых исходников, в общем-то просто синоним некоторой ревизии для SVN (в других системах это ессно не так). ... E>Понятно. Но скажи, ведь выделение tag не означает фиксацию абсолютно безошибочной версии. Обязательно будут находится ошибки, которые будут исправляться в branch-ах и куда-то затем должны помещаться. Т.е. выделяем tags/1.0.0. Правим первый баг, делаем новый tags/1.0.1. Затем исправляем следующий, получаем tags/1.0.2, и т.д. Допустим, исправляем пять багов и получаем пять тегов 1.0.<N> в tags. Это только для одного проекта. Правильно ли я понимаю, что ты предлагаешь (предпочитаешь) этот путь?
Таги не делаются так часто, таг это просто отметка какой-то логической точки в проекте (milestones, alpha, beta, gamma и т.п.). Баги в тагах не правятся, они правятся в основной ветке и когда достигается следующая логическая точка, то создаётся новый таг.
E>Теперь представим, что мы исправляли ошибки в подпроекте (например, oess_1), который, в свою очередь входит в подпроект so_4, который в свою очередь входит в подпроект aag_3. Итак, есть oess_1/tags/1.0.0, oess_1/tags/1.0.1 и т.д., oess_1/tags/1.0.5. Есть so_4/tags/4.3.2, который был построен на oess_1/tags/1.0.0. Что нужно сделать с so_4, чтобы перейти на oess_1/tags/1.0.5? Просто сменить externals в so_4/tags/4.3.2 или же создать новый тег so_4/tags/4.3.3? Наверное, создать новый тег, т.к. не факт, что исправление ошибки в oess_1/tags/1.0.5 не выявило какую-то скрытую ошибку в so_4. Итого, получается, что как только мы выделяем новый тег с bugfix-ом в подпроекте so_4, мы должны делать новый тег в so_4. Если so_4 зависит не только от oess_1, а еще от четырех подпроектов, то новый тег в so_4 будет создаваться при появлении нового тега в любом из подпроектов. И то же самое будет происходить в aag_3. Т.е. исправление на самом нижнем уровне пирамиды взаимосвязей проектов будет приводить к каскадному росту числа тегов к вершине пирамиды. E>Так это представляется мне. Или же ты пользуешься какой-то другой схемой?
В общем в этом случае уже используются brunches. Ты же не станешь использовать в проекте нестабильную библиотеку (аля trunk, tags), а вот стабильная на некоторый момент версия (в некотором роде) и должна выносится в новую ветку, ака 'alpha 0.29', 'release 1.0' ... практически все изменения в этих ветках должны попасть потом и в основную ветку (trunk).
E>А впечатление от самой статьи есть какие-нибудь?
Если закрыть глаза на неочевидность приёмов, а рассматривать применимость именно данной схемы, то очень неплохо. И её очень хорошо рассматривать как один из вариантов гайдлайнсов для разработки, на базе которого можно построить более подходящий (ср. RSDN Coding Conventions GuideLines).
Здравствуйте, Andir, Вы писали:
E>>Понятно. Но скажи, ведь выделение tag не означает фиксацию абсолютно безошибочной версии. Обязательно будут находится ошибки, которые будут исправляться в branch-ах и куда-то затем должны помещаться. Т.е. выделяем tags/1.0.0. Правим первый баг, делаем новый tags/1.0.1. Затем исправляем следующий, получаем tags/1.0.2, и т.д. Допустим, исправляем пять багов и получаем пять тегов 1.0.<N> в tags. Это только для одного проекта. Правильно ли я понимаю, что ты предлагаешь (предпочитаешь) этот путь?
A>Таги не делаются так часто, таг это просто отметка какой-то логической точки в проекте (milestones, alpha, beta, gamma и т.п.). Баги в тагах не правятся, они правятся в основной ветке и когда достигается следующая логическая точка, то создаётся новый таг.
Если я правильно понимаю, ты предлагаешь, зная про наличие багов в каком-то tag-е, не изменять его до тех пор, пока не подойдет какая-нибудь очередная логическая точка. Т.е., мы оказываемся в ситуации, когда говорим заказчику: да, проблема у нас есть, но мы ее исправим в ближайшей версии.
Имхо, такой способ будет подходить только для проектов, находящихся в активной стадии разработки. У которых логические точки следуют одна за другой достаточно часто.
Но, если речь идет не о прикладных проектах, а о библиотеках, то это далеко не всегда так. Особенно, если мы попробуем говорить о библиотеках для "внутреннего" пользования или OpenSource проектов (у которых нет жесткого графика развития и реализации). Вот, например, у меня есть библиотеки cls_2 и smart_ref_3, которые давно дошли до некой точки замерзания и уже давно законсервированы -- их возможностей с лихвой хватает для текущих нужд. Если в cls_2 обнаруживается баг или проблема под каким-то новым компилятором, я не могу отложить ее устранение на неопределенно долгий срок, т.к. вообще не уверен, будет ли в этом проекте следующая логическа точка. Я предпочитаю, чтобы cls_2 была приведена в работоспособное состояние как можно раньше.
Еще сложнее, когда исходники каких-то библиотек делаются доступными нашим заказчикам (например, через svn). Заказчик находит critical bug, из-за которого его разработка останавливается. Мы не можем тянуть с исправлением ошибки. И можем не иметь возможности сказать ему, подождите до версии 1.(N+1), т.к. у нас может быть с этим заказчиком договор только на предоставление ему версии 1.0 и поддержки ее (только поддержки, без предоставления новых версий) в течении некоторого срока. В таких условиях мне кажется более правильным закомитить bugfix в тот же tag и сделать этот bugfix сразу же доступным для заказчика.
E>>Теперь представим, что мы исправляли ошибки в подпроекте (например, oess_1), который, в свою очередь входит в подпроект so_4, который в свою очередь входит в подпроект aag_3. Итак, есть oess_1/tags/1.0.0, oess_1/tags/1.0.1 и т.д., oess_1/tags/1.0.5. Есть so_4/tags/4.3.2, который был построен на oess_1/tags/1.0.0. Что нужно сделать с so_4, чтобы перейти на oess_1/tags/1.0.5? Просто сменить externals в so_4/tags/4.3.2 или же создать новый тег so_4/tags/4.3.3? Наверное, создать новый тег, т.к. не факт, что исправление ошибки в oess_1/tags/1.0.5 не выявило какую-то скрытую ошибку в so_4. Итого, получается, что как только мы выделяем новый тег с bugfix-ом в подпроекте so_4, мы должны делать новый тег в so_4. Если so_4 зависит не только от oess_1, а еще от четырех подпроектов, то новый тег в so_4 будет создаваться при появлении нового тега в любом из подпроектов. И то же самое будет происходить в aag_3. Т.е. исправление на самом нижнем уровне пирамиды взаимосвязей проектов будет приводить к каскадному росту числа тегов к вершине пирамиды. E>>Так это представляется мне. Или же ты пользуешься какой-то другой схемой?
A>В общем в этом случае уже используются brunches. Ты же не станешь использовать в проекте нестабильную библиотеку (аля trunk, tags), а вот стабильная на некоторый момент версия (в некотором роде) и должна выносится в новую ветку, ака 'alpha 0.29', 'release 1.0' ... практически все изменения в этих ветках должны попасть потом и в основную ветку (trunk).
Кстати, иногда использую. Например, сейчас у меня есть проект so_sysconf_2, который остановился в branches/2.3. Он достиг стабильной, рабочей версии, но еще не протестирован на всех платформах. Поэтому проекты, которым нужна функциональность из 2.3 уже используют его. В branches/2.3 не будет расширения функциональности, это уже замороженная версия. Если все же расширение потребуется, то я просто скопирую branches/2.3 в branches/2.3.1. Но я не вижу большого смысла делать копию в tags/2.3.beta1.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Структура проектов на C++ с использованием Subversion
Здравствуйте, Andir, Вы писали:
A>Я вообще-то не удивлён, что такие пространства имён не используются, потому как это скорее напоминает заплатку для версионности АПИ, чем для реального разделения по пространствам имён (как я понимаю делается это для того, чтобы избавится от несовместимостей АПИ в разных версиях библиотеки), какие проблемы будет решать такая конвенция наименования? .
Это наименование должно позволить решить проблему одновременного использования разных версий (поколений) проектов в одном монолитном проекте.
Например, сейчас у нас используются два протокола для работы с клиентами: mbsms_1 и mbsms_2. Новые клиенты подключаются по mbsms_2, старые по mbsms_1. Сам сервер использует mbsms_2. Для того, чтобы сервер не заморачивался на поддержку mbsms_1 сделан mbsms_gate, который автоматически конвертирует mbsms_1 в mbsms_2 и обратно. Т.е. для сервера все подключения идут только через mbsms_2.
Так вот в mbsms_gate нужно одновременно использовать код mbsms_1 и mbsms_2. В этих библиотеках пересечение имен близко к 95% (если не к 99%): одни и те же названия заголовочных файлов, одни и те же названия namespace/классов/констант/функций, одни и те же названия библиотек. Единственное, что позволяет их отличать -- это номер поколения проекта в самом верхнем пространстве имен. Это позволяет мне в одном исходном файле mbsms_gate использовать обе библиотеки одновременно. Например:
Подгрузка заголовочных файлов:
Использование классов из разных пространств имен одновременно:
/*!
\brief Конвертирует результат отсылки SMS из mbsms_2 в mbsms_1.
*/
mbapi_3::result_shptr_t
convert_v2result( const mbapi_3::result_t & r )
{
if( mbsms_2::routing_failure_result_t::result_type == r.query_type() )
// Этого типа в mbsms_1 не было.
// Заменяем на mbsms_1::smpp_smsc_result_t.return mbapi_3::result_shptr_t(
// Возвращаем код ESME_RPROHIBITED.newmbsms_1::smpp_smsc_result_t( 0x101 ) );
if( mbsms_2::smpp_smsc_result_t::result_type == r.query_type() )
{
// Нужно сохранить SMPP command_status.const mbsms_2::smpp_smsc_result_t & v2result =
dynamic_cast< const mbsms_2::smpp_smsc_result_t & >( r );
return mbapi_3::result_shptr_t(
newmbsms_1::smpp_smsc_result_t(
v2result.query_command_status() ) );
}
// Сохраняем result тем же самым.return mbapi_3::result_shptr_t( r.clone() );
}
Линковаться к двум разным версиям библиотек одновременно:
Ничего подобного бы у меня не получилось, если бы я использовал для mbsms-библиотек пространство имен mbsms, путь к заголовочным файлам <mbsms/h>, библиотеки mbsms.lib.
A>2) При переходе с одной версии на другую, что предполагается делать? Есть ли вариант, что somenamespace_1::MyAPIFunction будет отличаться от somenamespace_2::MyAPIFunction порядком параметров, типом параметров, типом результата и т.п. (выбрасываемыми исключениями например ).
Просто адаптироваться к новым условиям работы. При этом ты явно знаешь, где тебе нужно что-то менять, т.к. видишь, где именно используются somenamespace_1.
A>3) Что произойдёт если я просто поменяю using namespace somenamespace_1 на using namespace somenamespace_2, могут ли при этом возникать ошибки логического плана, которые не так просто отследить в большом проекте?
Это зависит от конкретной задачи. Если изменения слишком серьезные, то простая замена, естественно, не пройдет.
Но, если какие-то куски функциональности существенно не изменились, то ничего страшного не будет. В уже показанном выше примере с mbsms_2 оказалось, что в большинстве случаев, в прикладном коде достаточно было просто сменить mbsms_1 на mbsms_2, и только в очень ограниченном числе мест реально потребовалась адаптация к новому протоколу. Но это была действительно серьезная адаптация.
В любом случае, если ты получаешь библиотеку с новым именем самого верхнего пространства имен, тебе приходится думать, как это отразиться на твоем коде. Поскольку просто так перекомпилировать старый код уже не получится. Если же ты получаешь новую версия с теми же самыми именами, то ты можешь даже успешно пройти компиляцию с новой версией. Только не факт, что программа после этого будет работать нормально.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Структура проектов на C++ с использованием Subversio
Ммм. Я так понимаю ты никогда не работал в CVS Там при всём желании исправить никакой таг нельзя — это просто логическая метка определённой ревизии ... Отсюда и вся логика. То есть то что ты называешь тагами, которые хочешь исправлять — это и есть brunches, только ты имена им даёшь 'tags'.
Здравствуйте, eao197, Вы писали:
E>В любом случае, если ты получаешь библиотеку с новым именем самого верхнего пространства имен, тебе приходится думать, как это отразиться на твоем коде. Поскольку просто так перекомпилировать старый код уже не получится. Если же ты получаешь новую версия с теми же самыми именами, то ты можешь даже успешно пройти компиляцию с новой версией. Только не факт, что программа после этого будет работать нормально.
Только из-за последнего пункта я бы отказался от такой практики Полагаю, что лучше было бы всё таки "заставлять" переделывать код под новое поколение библиотеки, или же не менять интерфейсы при этом, практикуя "чёрный ящик".
А вообще всё понял, спасибо.
Здравствуйте, Andir, Вы писали:
A>Ммм. Я так понимаю ты никогда не работал в CVS Там при всём желании исправить никакой таг нельзя — это просто логическая метка определённой ревизии ... Отсюда и вся логика. То есть то что ты называешь тагами, которые хочешь исправлять — это и есть brunches, только ты имена им даёшь 'tags'.
Для с CVS не работал, бог миловал
Все, что я говорил, относится именно к Subversion.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Структура проектов на C++ с использованием Subversion
E>Я в статье описываю идею добавления в имя верхнего пространства имен номера версии (т.е. oess_1, so_4, smart_ref_3 и т.д.). Но нигде больше подобных вещей не видел. До недавнего времени. В мартовском выпуске "ACE News and Tips Newsletter" говорится буквально следующее: E>
E>The ACE Namespace Versioning provides a means for ACE-based application developers to avoid symbol conflicts by using versioned namespaces...
E>
(раздел 17.4.4 "Использование пространств имен для управления версиями"). Впервые данный способ продемонстрирован Страуструпу Тандж Беннет (Tanj Bennett).
Там же приводится способ уменьшеня проблем сопровождения собственного кода, который использует библиотеки с подобными пространствами имен. Создается вспомогательный файл:
// ace_ns.hppnamespace ACE = ACE_5_5_0;
затем файл ace_ns.hpp используется при работе с библиотекой ACE:
#include"ace_ns.hpp"class MyReactor : public ACE::ACE_Reactor { ... };
При необходимости смены версии ACE достаточно поменять только строчку в ace_ns.hpp.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
... полез смотреть логи 
