Как управлять «сторонними» подпроектами в Perforce? - PullRequest
Новая
       7

Как управлять «сторонними» подпроектами в Perforce?

1 голос
/ 22 марта 2011

Наша группа объединяет несколько различных подблоков в наш основной проект, и мы пытаемся определить наилучший способ управления всеми этими различными частями интеллектуальной собственности. (С этого момента я буду называть эти подпроекты частями ИС «Интеллектуальная собственность»).

IP будет представлять собой смесь IP-адреса стороннего поставщика, IP-адреса предыдущих проектов и нового IP-адреса этого проекта. Вот некоторые идеи, которые мы рассматриваем для управления различными частями IP:

  1. Публикация выпусков на физическом диске и указание главному проекту правильных выпусков.

    PROS - От SCM практически нет зависимостей: кажется, проще управлять на начальном этапе:

    CONS - Не забывайте постоянно обновлять каждый центр проектирования:

  2. Используйте представления спецификации клиента Perforce, чтобы включить правильную версию.

    PROS - Возможность быстро увидеть, какие IP-адреса используются в спецификации клиента:

    CONS - со многими IP-адресами клиентская спецификация становится очень грязной и сложной для управления: каждый член команды управляет своей собственной клиентской спецификацией (несоответствия): сама вещь, определяющая, какую версию IP использовать, не относится к SCM (по умолчанию) :

  3. Интеграция различных выпусков в одноканальное представление клиента.

    PROS - упрощает обслуживание спецификаций клиента: любое изменение IP-версии легко наблюдать с помощью стандартных инструментов Perforce:

    CONS - Не так просто увидеть, какие версии IP мы используем:

Наш менеджер предпочитает №2, потому что ему проще всего посмотреть спецификацию клиента и узнать все IP-адреса, которые мы используем, и версии. Рабочим пчелам, как правило, сильно не нравится этот, так как это означает, что мы должны стараться поддерживать все индивидуальные спецификации клиента в актуальном состоянии и не подпадаем под SCM самого проекта.

Как другие обращаются с IP в проекте Perforce и какие у вас рекомендации?

UPDATE:

Я действительно склоняюсь к решению № 3, оно кажется намного чище и проще в обслуживании. Если кто-нибудь может подумать о том, почему №3 не очень хорошая идея, пожалуйста, дайте мне знать.

Ответы [ 3 ]

3 голосов
/ 23 марта 2011

Я бы тоже выбрал третье решение.

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

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

Также, если вы посмотрите «хранилища спецификаций» в справкеВы можете настроить Perforce так, чтобы версия автоматически контролировала все спецификации, включая спецификации веток, что даст вам возможность отслеживания, если вы измените версии IP.

0 голосов
/ 26 марта 2011

Я бы предложил # 2, так как это самая прозрачная система. Да, это будет означать дополнительную работу по поддержанию клиентов в актуальном состоянии, но вы можете минимизировать эту проблему, используя шаблоны клиентов.

В своей работе мы используем шаблонные клиенты, с которых копируют разработчики, для правильной настройки своих клиентов. Мы называем это шаблоном «0-PRODUCT-BRANCH» (и иногда добавляем платформу при необходимости). Затем это однострочная команда из командной строки или пара кликов из графического интерфейса для обновления вашего клиента. Я отправляю уведомления команде каждый раз, когда шаблон меняется.

Теперь в моем случае изменения шаблона происходят не очень часто. Может быть, максимум 5-6 в год, поэтому уровень хлопот для вас может быть разным.

0 голосов
/ 22 марта 2011

"каждый член команды управляет своей собственной спецификацией клиента (несоответствия)"

Не делайте этого.Пусть спецификацией клиента будет файл, зарегистрированный в Perforce.

...