CVS: Модули и Подкаталоги

Question

Кто-нибудь знает, каков наилучший подход для определения структуры модулей / каталогов в CVS? В частности, что если у меня большой проект, который может иметь много подпроектов (даже не связанных). Лучше определить модуль для каждого подпроекта или использовать подкаталоги:

1. Модули подхода № 1

   • CVSROOT
     • Основной проект
     • Платформа A Подпроект1
     • Платформа A Подпроект2
     • Платформа B Подпроект3
     • ...

2. Подкаталоги подхода № 2

   • CVSROOT
     • Проект
       • Главная
       • Платформа А
         • Подпроект 1
         • Подпроект 2
       • Платформа B
         • Подпроект 3
       • ...

Answer 1

От пользователя и отъезда вы не можете сказать. Я даже смешал и сопоставил. По сути, если он находит его в модулях, он использует то, что говорит модуль, но если нет, он предполагает, что это подкаталог и пытается это сделать.

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

Answer 2

Я смешиваю и сопоставляю.

например. Я CVS'ed мой домашний каталог около 20 лет. (Сейчас я использую hg и / или git.)

Не только мой домашний каталог, но и множество разных проектов и инструментов. Не связано, кроме того, что я над ними работал. Все они находятся в моем домашнем каталоге, в таких местах, как ~ glew / src

Подкаталоги требуют меньше ресурсов для обслуживания.

Модули - это то, что вам нужно, если вам нужно собрать несколько подкаталогов в один логический модуль.

например. некоторые из моих инструментов живут в таких местах, как ~ / src / tool1, ~ / src / tool2.

Некоторые из них имеют общие черты ~ / src / my-lib

Я не хочу, чтобы люди забирали все ~ glew / src, чтобы использовать ~ / tool1. То есть Я хочу, чтобы они могли оформить заказ только на tool1 и получить все, что им нужно. Я не хочу, чтобы они проверяли ~ / src / tool1, затем ~ / src / my-lib, а затем ~ / src / my-lib2 ...

Итак, я создаю модуль, используя &, чтобы при извлечении tool1 они также получали экземпляр ~ / src / my-lib как tool1 / import / my-lib. И так далее.

Answer 3

Если есть проекты, особенно не связанные с основным - я бы занялся созданием модулей для каждого из них. Попробуйте спросить себя - почему вы хотите сгруппировать все, даже не связанные непосредственно вещи, в одно пространство? Разве не было бы более структурированным разделять вещи?

Немного не по теме, но все же полезно: иногда в IDE проще управлять отдельными модулями. Например. Затмение. У меня есть опыт работы с обоими способами - и каждый проект в качестве отдельного модуля - облегчает управление тегами позже - для тегирования / просмотра существующих тегов ...