Внешние элементы подрывной деятельности - это антипаттерн?

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

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

Я вообще не думаю, что это антипаттерн. Я сделал несколько быстрых поисков в Google и практически ничего не нашел ... никто не жалуется, что использование svn: externals плохо или вредно. Конечно, есть некоторые предостережения, о которых вы должны знать ... и это не то, что вы должны просто сильно разбрызгивать во все свои репозитории ... но что касается исходной цитаты, это всего лишь его личное (и субъективное) мнение . Он никогда особо не обсуждал svn: externals, за исключением того, что осуждал их как антипаттерн. Такие широкие заявления без какой-либо поддержки или хотя бы объяснения того, как человек пришел, чтобы сделать заявление, всегда вызывают подозрения.

Тем не менее, есть некоторые проблемы с использованием внешних элементов. Как ответил Майк, они могут быть очень полезны для указания на стабильные ветви выпущенного программного обеспечения ... особенно на программное обеспечение, которое вы уже контролируете. Мы используем их внутри ряда проектов для служебных библиотек и тому подобного. У нас есть небольшая группа, которая расширяет и работает над базой служебных библиотек, но этот базовый код используется в нескольких проектах. Мы не хотим, чтобы различные команды просто проверяли код служебного проекта, и мы не хотим иметь дело с миллионом веток, поэтому для нас svn: externals работает очень хорошо. Для некоторых людей они могут не быть ответом. Однако я категорически не согласен с утверждением «Пожалуйста, не используйте ...» и с тем, что эти инструменты представляют собой антипаттерн.

Если простой внешний является анти-шаблоном, потому что он может сломать ваш репозиторий, то репозиторий с явной ревизией не должен.

Выдержка из svn книга:

An externals definition is a mapping of a local directory to the URL**—and possibly a particular revision—**of a versioned resource.

Я думаю, все зависит от вашей цели использования этой функции, это не антипаттерн сам по себе.

Во внешних компонентах Subversion есть определенные недостатки, но мы, кажется, достаточно успешно используем их для включения библиотек (как наших, так и поставщиков), от которых зависит текущий проект. Так что я не считаю их «антипаттерном». Для меня важными моментами использования являются:

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

Я тоже был бы заинтересован в любых серьезных рисках этого соглашения и в лучших подходах.

Утверждение, что а это б не делает аб, если вы не скажете Зачем, это так.

Главный недостаток, который я вижу во внешних ссылках в Subversion, заключается в том, что вам не гарантируется наличие репозитория при обновлении вашей рабочей копии.

Внешние ссылки Subversion можно использовать и злоупотреблять, а особенность сама - не что иное, как особенность. Нельзя сказать, что это шаблон или антипаттерн.

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

Да, вы можете использовать его неправильно, не указав конкретно, какая версия справочника вам нужна. Это вызовет у вас проблемы? Вероятный!

Это антипаттерн? Смотря как. Если вы перейдете по ссылке, указанной автором цитируемого текста, т.е. здесь, то нет. Использование чего-то может для предоставления плохого решения не означает, что весь метод этого антипаттерн полностью. Если бы это было правилом, я бы сказал, что языки программирования в целом являются антипаттернами, потому что в каждом языке программирования вы может принимать плохие решения.

Старый поток, но я хочу решить проблему, связанную с тем, что изменение внешнего источника может нарушить ваш код. Как указывалось ранее, чаще всего это происходит из-за неправильного использования внешнего свойства. Внешние ссылки почти во всех случаях должны указывать на конкретный номер версии в URI внешнего репозитория. Это гарантирует, что внешний вид никогда не изменится, если вы не измените его так, чтобы он указывал на другой номер ревизии.

Для некоторых из наших внутренних библиотек, которые мы используем в качестве внешних в наших проектах для конечных пользователей, я счел полезным создать тег библиотеки в версии Major.Minor, где мы не применяем критических изменений. При использовании четырехточечной схемы управления версиями (Major.Minor.BugFix.Build) мы позволяем поддерживать актуальность тега с изменениями BugFix.Build (опять же, не применяя критических изменений). Это позволяет нам использовать внешнюю ссылку на тег без номера редакции. В случае серьезных или других критических изменений создается новый тег.

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