Действительно ли внешний облик подверсии является антишаблоном?

Я - автор котировки в вопросе, который прибыл из предыдущий ответ .

Джейсон прав с подозрением относиться к кратким сообщениям такой как мой и попросить объяснение. Конечно, если бы я полностью объяснил все в том ответе, я должен был бы написать книгу.

Майк также прав указать, что одна из проблем с svn:external - как особенность - то, что изменения в целенаправленном источнике могли сломать Ваш собственный источник, особенно если тот целенаправленный источник находится в хранилище, которым Вы не владеете.

В дальнейшем объяснении моего комментария, позвольте мне сначала сказать, что есть «безопасные» способы использовать svn:external - как особенность, так же, как с любым другим инструментом или особенностью. Однако я называю его антиобразец , потому что особенность, намного более вероятно, будет неправильно использоваться. По моему опыту, это всегда неправильно использовалось, и я оказываюсь очень вряд ли, чтобы когда-либо использовать его тем безопасным способом, ни когда-либо рекомендовать то использование. Пожалуйста, дальнейшее примечание, что я не значу умаления для команды Подрывной деятельности - я люблю Подрывную деятельность, хотя я планирую идти дальше на Базар.

основная проблема с этой особенностью - то, что она поощряет, и она обычно используется, чтобы непосредственно связать источник, каждый строит («проект») к источнику другого, или связать проект с набором из двух предметов (DLL, JAR, и т.д.), от которого она зависит. Ни одно из этого использования не мудро, и они составляют антиобразец.

, Поскольку я сказал в своем другом ответе, я полагаю, что существенный принцип для программного обеспечения строит, то, что каждый проект строит точно ОДИН двойной или основной результат. Это может быть рассмотрено заявление принципа разделение проблем к процессу сборки. Это особенно верно относительно одного проекта, непосредственно ссылающегося на источник другого, который является также нарушением принципа герметизация . Другая форма этого вида нарушения пытается создать построить иерархию, чтобы построить всю систему, или подсистема рекурсивным призывом подстроит. Знаток сильно мотивирует/приводит в исполнение это поведение, которое является одной из многих причин, что я не рекомендую это.

Наконец, я нахожу, что есть различные практические вопросы, которые делают этого нежелательного особенности. Для один, svn:external имеет некоторые интересные поведенческие особенности (но детали избегают меня в настоящий момент). Для другого я всегда нахожу, что мне нужны такие зависимости, чтобы быть явно видимым к моему проекту (процесс сборки), не похороненный как некоторые исходные метаданные контроля.

Так, что такое «безопасный» способ использования этой функции? Я полагал бы, что, чтобы быть, когда это используется временно только одним человеком, таким как способ «сконфигурировать» производственные условия. Я видел, где программист мог бы создать их собственную папку в хранилище (или один для каждого программиста), где они сконфигурируют svn:external ссылки с различными другими частями хранилища, что они в настоящее время продолжают работать. Затем оформление заказа которого одна папка создаст рабочую копию всех их текущих проектов. Когда проект добавлен или закончен, эти svn:external, определения могли быть скорректированы, и рабочая копия обновлена соответственно. Однако я предпочитаю подход, который не связан с конкретной исходной системой управления, такой как выполнение этого со сценарием, который призывает контроль.

Для записи, моя новая подверженность этой проблеме произошла в течение лета 2008 года в консультационном клиенте, который использовал svn:external в крупном масштабе - ВСЕ было поперечный связано, чтобы создать единственную основную рабочую копию. Их Муравей & находящийся в Jython (для WebLogic) строят сценарии, были построены сверху этой основной рабочей копии. Конечный результат: НИЧТО не могло быть построено автономное, были буквально десятки подпроектов, но не каждый был безопасен к оформлению заказа/работе на отдельно. Поэтому любая работа над этой системой сначала потребовала оформления заказа/обновления более чем 2 ГБ файлов (они помещают наборы из двух предметов в хранилище также). Получение чего-либо сделанного было упражнением в тщетности, и я уехал после попытки в течение трех месяцев (было много других настоящих антиобразцов также).

ОТРЕДАКТИРУЙТЕ: Рассуждайте рекурсивный, строит -

За эти годы (особенно в прошлое десятилетие), я построил крупные системы для компаний Fortune 500 и крупные правительственные учреждения, включающие много десятков подпроектов, устроенных в директивных иерархиях, которые являются многими уровнями глубоко. Я использовал проекты/решения Microsoft Visual Studio организовать основанные НА.NET системы, Муравья или Знатока 2 для явских систем, и я начал использовать distutils и setuptools (easyinstall) для Основанных на питоне систем. Эти системы также обычно включали огромные базы данных в Oracle или Microsoft SQL Server.

я имел большой успех, проектируя их крупные, строит для простоты использования и воспроизводимости. Мои нормы проектирования - то, что новый разработчик может обнаружиться в их первый день, быть дан новое автоматизированное рабочее место (возможно, прямо от Dell только с типичной установкой OS), быть дан простой документ установки (обычно всего одна страница инсталляционных инструкций), и быть в состоянии к полностью установке автоматизированное рабочее место и построить полную систему из источника, безнадзорного, без помощи, и через половину дня или меньше. Призыв строения себя включает открытие раковины команды, изменение на корневой каталог исходного дерева и давание короткой команды, чтобы построить ВСЕ.

Несмотря на тот успех, строя такое крупное строят систему, требует отличного ухода и близкой приверженности существенным принципам разработки, так же, как со строительством крупного критически важного для бизнеса применения/системы. Я нашел, что ключевая роль - то, что у каждого проекта (который производит единственный артефакт/результат) должен быть сингл, строят сценарий, у которого должен быть четко определенный интерфейс (команды для призыва частей процесса сборки), и он должен одинокий из всех других (sub) проектов. Исторически, легко построить целую систему, но твердый/невозможный построить только одну часть. Только недавно изучите меня, чтобы тщательно гарантировать, что каждый проект действительно стоит один.

На практике, это означает, что должно быть по крайней мере два уровня, строят сценарии. Нижний слой - проект, строят сценарии, которые производят каждый результат/артефакт. Каждый такой сценарий находится в корневом каталоге его исходного дерева проекта (действительно, этот сценарий ОПРЕДЕЛЯЕТ свое исходное дерево проекта), эти сценарии ничего не знают об исходном контроле, они ожидают управляться из командной строки, они ссылаются на все в проекте относительно построить сценария, и они ссылаются на свои внешние зависимости (инструменты или двойные артефакты, никакие другие исходные проекты) на основе нескольких конфигурируемых установок (переменные окружения, конфигурационные файлы, и т.д.).

второй уровень строит сценарии, также предназначен, чтобы быть призванным из командной строки, но они знают об исходном контроле. Действительно, этот второй уровень часто - единственный сценарий, который призван с названием проекта и версией, тогда он проверяет источник для названного проекта к новому временному справочнику (возможно, указанный на командной строке) и призывает строить сценарий.

, возможно, должно быть больше изменения, чтобы приспособить непрерывные серверы интеграции, несколько платформ и различных сценариев выпуска.

Иногда есть потребность в третьем уровне сценариев, который призывает второй уровень сценариев (которые призывают первый уровень) в целях строительства определенных подмножеств полного набора проекта. Например, у каждого разработчика может быть их собственный сценарий, который разрабатывает проекты, что они продолжают работать сегодня. Может быть сценарий, чтобы построить все, чтобы генерировать основную документацию, или вычислить метрики.

Невнимательный, я нашел, что попытка рассматривать систему как иерархию проектов контрпродуктивна. Это связывает проекты друг с другом так, чтобы они не могли быть свободно построены одни, или в произвольных местоположениях (временный справочник на непрерывном сервере интеграции), или в произвольном порядке (предполагающий, что зависимости удовлетворены). Часто, попытка вызвать иерархию ломает любую интеграцию IDE, которой можно было бы делать попытку.

Наконец, строя крупную иерархию проектов может просто быть также интенсивная производительность. Например, в течение весны 2007 года я делал попытку умеренной исходной иерархии (Ява плюс Oracle), что я построил Муравья использования, который в конечном счете потерпел неудачу потому что строение всегда прерываемого с Явским OutOfMemoryException. Это было на автоматизированном рабочем месте RAM на 2 ГБ с областью подкачки на 3.5 ГБ, для которой я настроил JVM, чтобы быть в состоянии использовать всю доступную память. Применение/система было относительно тривиально с точки зрения объема кода, но рекурсивные строят просьбы, в конечном счете исчерпал память, неважно, сколько памяти я дал ему. Конечно, это также взяло навсегда, чтобы выполнить также (30-60 минут было распространено, прежде чем это прервалось). Я знаю, как настроиться Очень хорошо, но в конечном счете я просто превышал лимиты инструментов (Ява/Муравей в этом случае).

Так делают себе одолжение, строят Ваш строить как автономные проекты, затем составляют их в полную систему. Сохраните это легким и гибким. Наслаждаться.

РЕДАКТИРУЕТ: Больше на антиобразцах

Строго говоря, антиобразец общим решением, которое похожее на него, решает проблему, но делать, или потому что он оставляет важные разрывы или потому что он вводит дополнительные проблемы (часто хуже, чем оригинальная проблема). Решение обязательно включает один или несколько инструментов плюс техника для применения их к проблеме под рукой. Поэтому это быть протяжение, чтобы относящееся к инструменту или определенной особенности инструмента как антиобразец, и кажущееся, что люди обнаруживающие и реагирующие на то протяжение - достаточно ярмарка.

, С другой стороны, так как это, кажется, быть обычной практикой в нашей промышленности, чтобы фокусирующееся на инструментах, а не технике, это быть инструмент/особенность, который привлекает внимание (случайное исследование вопросов здесь на StackOverflow, кажется, легко иллюстрировать). Мои комментарии и этот вопрос сам, отражает ту практику.

Однако иногда это кажущееся особенно оправданным, чтобы заставлять это простираться, такой как в этом случае. Некоторые инструменты, казаться, «приводить» пользователя к конкретным методам для применения их, до такой степени, когда некоторые утверждает, что инструменты формирует мысль (немного перефразированный). Главным образом в том духе я предполагает, что svn:external быть антиобразец.

К более строго государственному проблема, антиобразец к дизайну a, строить решение, которое включает сходящиеся проекты в исходный уровень, или неявно присваиваемое версию зависимостям между проектами или позволять таким зависимостям неявно изменяться, потому что каждый из них призывает очень негативные последствия. Природа svn:external - как особенность делала предотвращение тех негативных последствий очень трудным.

Правильно обработка зависимостей между проектами включала обращение к тем движущим силам наряду с основной проблемой, и инструменты и методы ведет вниз другой путь. Пример, который рассмотрел, Айви , который помогает в способе, подобном Знатоку, но без многих недостатков. Я расследующий Айви, вместе с Муравьем, поскольку мое краткосрочное решение Явы строит проблему. Длительный срок, я - включать основные понятия и характеристики в общедоступный инструмент, который является многоплатформенным решением.