Имеет ли это смысл?Если это так, есть ли способ обойти эту проблему?Если это не так, то почему бы и нет, и что мы должны вместо этого делать?
Как уже сказал prodigitalson , внешний элемент в SVN в основном считается совершенно другим программным обеспечением, сего собственные циклы выпуска, ветви, теги и т. д. В соответствии с этой моделью вам вообще не нужно прикреплять внешние элементы в какой-либо ствол, а прикреплять их все к тегу или ревизии.Это довольно ограниченная модель использования кода из внешних источников, но это то, что поддерживает SVN.Уходи от этого, и ты сам по себе.(См. Ниже мою личную военную историю об этом.)
Еще одна вещь, которую я бы пересмотрел, если бы я был вами, ссылается на другое хранилище.IME ссылается на внешний относительно текущего проекта или корня хранилища гораздо лучше, чем с использованием абсолютных путей.Просто подумайте о том, что вы можете изменить протокол с svn: на, скажем, https:.(Я видел, как это происходило с компанией, и, несмотря на то, что для изменения всех внешних элементов в значительной степени полагался на сценарии, этот переход был беспорядком, о котором все участвуют, и у него постоянно возникают кошмары.) Относительные пути к внешним элементам просто более устойчивы, но они доступны только внутриединый репозиторий.
Компания, в которой я работаю, только что столкнулась с подобной проблемой.У нас много кода, который распределяется между разными продуктами.Это делается с помощью внешних элементов, и эти проекты с внешними ссылками имеют внешние элементы.В некоторых местах мы дошли до трех слоев рекурсивного внешнего вида, и мы уже знаем, что в будущем их будет больше.Весь этот код обрабатывается постоянно, и мы хотели бы, чтобы внешние ссылки ссылались на основную часть проектов, на которые они ссылаются, потому что автоматическое тестирование снимает это преимущество, а управление выпусками всех этих рекурсивных внешних элементов потребовало бы усилий, которые мы просто не можем себе позволить.
Но разветвление проекта в этом параметре - настоящая боль в шее , потому что недостаточно закрепить внешние элементы проекта, когда сами они ссылаются на неподкрепленные внешние элементы.Всякий раз, когда вам нужно выполнить ветвь проекта foo до foo', который через внешний источник ссылается на проект X, который, в свою очередь, через внешний источник ссылается на проект XX, вам потребуется ветка foo'XX, который является внешним в foo' ветви X, который является внешним по отношению к foo'.Представьте себе полдюжины внешних элементов в foo, половина из которых имеет свои собственные внешние элементы, некоторые рекурсивные три или более слоев, и вы достигнете точки, когда проект XXX изобилует ветвями, созданными для проектов, о которых он даже не должен знать,
Наше решение состоит в том, чтобы либо рекурсивно либо A) заменить все внешние элементы ветвью, на которую они ссылались, либо B) настроить ответвление внешнего X in foo/branches/externals/foo'/X, на который ссылается <project>/branches/foo' (с самим foo/branches/externals/foo'/X, ссылающимся на foo/branches/externals/foo'/XX).Однако настройка этого при создании foo' невероятно сложна и дает более чем достаточно шансов для совершения глупых ошибок, поэтому мы используем сценарии для рекурсивного спуска проекта и его внешних компонентов и делаем все это.