Организация репозитория Subversion из тысяч элементов

Question

Прежде чем я начну:Я провел много времени на многих форумах (включая Stack Overflow - и да, есть много вопросов SO по организации svn), искал в Google и читал документы (у меня есть несколько книг по Subversion).Я до сих пор не нашел хорошего способа организовать нашу кодовую базу в Subversion.В настоящее время мы используем RCS в качестве нашей системы контроля версий, и все хранится в 1 каталоге RCS - некрасиво, я знаю - поэтому я работаю над чем-то лучшим.Я также много использовал Subversion, поэтому знаю ее возможности и то, как она работает.Я несколько месяцев колебался, задавая этот вопрос, поскольку он не совсем связан с программированием, но поскольку я не смог прийти к решению, где лучше задать свой вопрос!

Что усложняет ситуацию в моей голове, так это подрывной термин «Проект».Если я хочу управлять Java-проектом в Subversion, для меня это имеет смысл:все Java-файлы, которые объединяются в файл jar, можно считать «Проектом» — все они принадлежат друг другу.Однако в нашей среде я не вижу простого способа определить, что такое «проект».У нас более 4000 программ, и все они практически не зависят друг от друга.Многие из них представляют собой сценарии оболочки или сценарии Perl.Некоторые из наших сценариев используют общие «служебные» или «библиотечные» сценарии, но по большей части все объекты кода независимы.

Один «Проект» в нашей среде может включать программы A, B и C, а также файл конфигурации AA.Другой проект может использовать программы C, D и E и файл конфигурации BB.Еще одним проектом может быть просто изменение файла конфигурации AA или, может быть, программы B.Невозможно классифицировать, какие программы или файлы принадлежат группе.Из-за этого я понятия не имею, как организовать наш код в Subversion.Я мог бы поместить все в основной ствол проекта, но тогда проверка рабочей копии означает проверку всех 4000+ элементов.

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

Возможно, Subversion нам не подходит, хотя я верю, что она может работать.У нас уже есть сервер Subversion для нашего веб-кода и наших Java-программ, и он отлично работает, поскольку есть легко определяемые проекты.Я просто не могу понять, как организовать нашу основную библиотеку кода.

Надеюсь, что-то из этого имело смысл...Заранее спасибо за вашу мудрость!

Answer 1

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

Таким образом, вы можете создать «настоящий» каталог для каждого компонента, а затем создать отдельный каталог для каждого проекта, который будет использовать внешние ресурсы для извлечения необходимых компонентов.

Answer 2

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

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

Subversion действительно отражает файловую систему, поэтому, если она выглядит некрасиво в файловой системе, она не будет выглядеть красиво и в Subversion.

Если вы хотите избежать реорганизации файлов, возможно, вы сможете найти систему контроля версий, которая позволит вам возвращать/извлекать файлы на основе тегов, а не на основе их местоположения в файловой системе.