здесь нет «хорошего» ответа, но я думаю, что следует проводить различие между репозиториями SVN, которые содержат 1 или 2 проекта, и другими, которые содержат 100.
Я поддерживаю репозиторий SVN, который был перенесен из VSS, в нем несколько сотен «проектов», ни один из них не был организован в соответствии со структурой trunk / branch / tag (на самом деле я думаю, что структура действительно ненужна и бесполезна) после того, как я какое-то время использовал SVN, это, безусловно, не поможет, когда вам нужно пометить 2 или 3 проекта как одно изменение).
Мы поддерживаем каталог проекта для всего нашего поддерживаемого программного обеспечения, в котором у нас есть подкаталоги для конфигурации и еще один для источника. Под этими номерами у нас есть номера версий продукта - так эффективно мы отбрасываем концепцию транка, у нас есть только каталоги тегов - самое большое число является транком (мы должны сделать это, поскольку мы должны поддерживать несколько версий проектов одновременно). Слияние происходит по мере необходимости, поэтому, если я обновлю ошибку в проекте А, версия 3.0; Я объединю эти изменения в версии 4.0 и v5.0.
Если бы я делал репо только с 1 или 2 проектами, у меня может возникнуть соблазн сохранить структуру ветви / тега, но с другой стороны - я бы, вероятно, оставил каталоги явным образом в главном дереве (при условии, что я не выпускался достаточно часто, чтобы помечать теги регулярно) (я использую номер ревизии в качестве «тега», кстати, и храню там двоичные файлы. Поэтому, если мне нужно получить конкретную старую ревизию, я могу получить нужный двоичный файл, посмотрев на бревно)
На удивление легко управлять, учитывая, что у меня репо 10 Гб с ревнумом в настоящее время выше 300 000 с большим количеством старого кода и новым. Я бы порекомендовал эту структуру другим и буду использовать ее снова.
Кстати, еще одна причина, по которой теги dir не будут работать для нас, заключается в том, что мы выпускаем каждый раз, когда появляется ошибка или запрос на изменение, независимо от того, насколько он крошечный. Наш каталог тегов через некоторое время станет неуправляемым, поэтому мы используем revnum в качестве тега - мы можем связать его с трекером ошибок, чтобы сделать его более удобным для чтения человеком.
Итак, чтобы подвести итог, мы имеем такую структуру каталогов, где v1 и v2 - версии продукта:
maint/source/v1.0/projectA
maint/source/v1.0/projectB
maint/source/v2.0/projectA
maint/source/v2.0/projectB
etc
очевидно, мы могли бы поместить dir филиала в 'source', а также ветку / tag в каждом подпроекте, но это было бы сложно, если бы нам нужно было выпустить 2 подпроекта как один запрос на изменение (как мы это делаем довольно часто). Помещение тега subdir в исходный каталог означает, что мы помечаем все, когда изменяется только один подпроект (что не соответствует нашему требованию отслеживать каждый подпроект отдельно)