Нормально ли, что внешние файлы SVN не фиксируются?

Когда вы устанавливаете свойство externals, файлы из внешнего репозитория не копируются в ваш рабочий репозиторий. Скорее, он просто создает «заметку» о том, откуда в будущем можно получить эти файлы.

Таким образом, когда вы создаете свой тег, svn не копирует фактические файлы, на которые есть внешние ссылки. Вместо этого он просто копирует «заметку». Если бы вы выполнили извлечение каталога tags/1.0.1 (или обновление, если оно уже извлечено локально), вы бы заметили, что соответствующие внешние файлы будут правильно извлечены, даже если эти файлы не существуют в рабочем репозитории.

редактировать:

О, наконец-то я увидел проблему. Вы устанавливаете свой внешний в корневом каталоге, а не в магистральном каталоге.

Лучший способ увидеть svn — это просто файловая система, вся идея ствола, тегов и ветвей — это просто концептуальные идеи, и каждый каталог ничем не отличается от другого.

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

Следующая команда:

svn propget svn:externals file:///Z:/Projects/workB/trunk

должен вывести:

file:///Z:/repos/repoA/trunk/lib lib 

Ваше ожидание правильное. Копия svn должна создавать 100% копию исходного объекта, т. е. внешнее определение (и содержимое) должно отображаться в теге

1. Проверить svn ls -v -R file:///Z:/repos/repoB/tags/1.0.1
2. Для облегчения проверки и устранения неполадок я предлагаю перейти в общедоступный набор репозиториев - для тестирования вы можете, например, создать на Assembla свободное пространство с двумя или более SVN-репозиториями.

Не имеет отношения к примечанию о проблеме: тег, по соглашению, используется как точка заморозки кода (позже из любой точки можно получить точно такой же код), но он означает, что вы также должны быть заблокированы все внешние элементы в состоянии создания тега. repos/repoA/trunk/lib — это ревизия HEAD, которая менялась со временем, и соответствующая ревизия (тег ссылки rev — lib rev) для тега 1.0.1 будет утеряна. Читать о PEG-ревизиях

Изменить

Протестировано репозиторий Assembla с расширением в багажнике. Тест не пройден:

>svn co https://subversion.assembla.com/svn/subversion-troubleshoot-b/trunk .
A    core_mod.txt
Checked out revision 4

только там мне пришлось проверить также папку /lib

Изменить2

Для репозитория subversion-troubleshoot-b: исправления применены к определению, создан правильно написанный тег (1.0.1) с внешней привязкой к PEG-ревизии

См. различия между транком и проверкой тегов

z:\>svn co https://subversion.assembla.com/svn/subversion-troubleshoot-b/
...

Fetching external item into 'subversion-troubleshoot-b\trunk\lib':
A    subversion-troubleshoot-b\trunk\lib\lib01.txt
Checked out external at revision 4.

Fetching external item into 'subversion-troubleshoot-b\tags\1.0.1\lib':
A    subversion-troubleshoot-b\tags\1.0.1\lib\lib01.txt
Checked out external at revision 2.

Checked out revision 7.

если вы позже измените библиотеку в связанном репо - ствол будет получать последнее содержимое папки, 1.0.1 - всегда будет с версией 2 библиотеки в subversion-troubleshoot