Обработка отношений между несколькими проектами подрывных

голоса
4

В моей компании мы используем одно хранилище SVN, чтобы держать наш C ++ кода. Базовый код состоит из общей части (инфраструктуры и приложений) и клиентских проектов (разработка в виде плагинов).

Макет хранилища выглядит следующим образом:

  • инфраструктура
  • App1
  • App2
  • App3
  • проект-для-клиент-1
    • App1-плагин
    • App2-плагин
    • конфигурация
  • проект-для-клиент-2
    • App1-плагин
    • App2-плагин
    • конфигурация

Типичный релиз для проекта клиента включает в себя проектные данные и каждый проект, который используется им (например, инфраструктура).

Фактическое расположение каждой директории -

  • инфраструктура
    • ветви
    • теги
    • хобот
  • проект-для-клиент-2
    • ветви
    • теги
    • хобот

И то же самое для остальных проектов.

У нас есть несколько проблем с выше расположением:

  1. Это трудно начать новую среду разработки для проекта клиента, так как необходимо оформить все из участвующих проектов (например: инфраструктура, App1, App2, проект-для-клиент-1).
  2. Это трудно пометить релиз в клиенте проектов, по той же причине, что и выше.
  3. В случае, если проект клиента необходимо изменить общий код (например, инфраструктура), мы иногда используем ветку. Это трудно отслеживать, какие отрасли используются в проектах.

Есть ли способ в SVN решить любого из вышеперечисленных? Я думал об использовании SVN: внешние ссылки в клиентских проектах, но после прочтения этого поста я понимаю , что это не может быть правильным выбором.

Задан 10/09/2009 в 13:46
источник пользователем
На других языках...                            


5 ответов

голоса
3

Вы могли бы справиться с этим с SVN: внешние ссылки. Это гиперссылка на место в качестве SVN репо Это позволяет тянуть в части другого хранилища (или же). Один из способов использовать это в рамках проекта-за-client2, вы добавляете SVN: внешние ссылки на отрасль инфраструктуры нужно, филиал App1 вам нужно, и т.д. Так что, когда вы заканчивали проект-для-client2, вы получите все правильные части.

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

Ответил 10/09/2009 в 14:36
источник пользователем

голоса
2

Во-первых, я не согласен, что внешние злы. Несмотря на то, что они не являются совершенными.

На данный момент вы делаете несколько извлечений, чтобы создать рабочую копию. Если вы использовали внешние ссылки он будет делать именно это, но автоматически и последовательно каждый раз.

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

Экстерналии не являются панацеей - и, как пост показывает, что могут быть проблемы. Я уверен, что есть что-то лучше, чем внешнеположенности, но я не нашел еще (даже концептуально). Конечно, структуру вы используете может дать много информации и управления в процессе разработки, используя внешние можно добавить к этому. Тем не менее, проблемы у него была не фундаментальные проблемы коррупции - чистый прибудет бы решить все, и довольно редко (вы на самом деле не в состоянии создать новую ветвь библиотеки в вашем репо?).

Вопросы для рассмотрения - с помощью рекурсивных внешних ссылок. Я не продаются на или да или нет, и это, как правило, идут с прагматичным подходом.

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

Ответил 10/09/2009 в 15:29
источник пользователем

голоса
2

Предложение, чтобы изменить расположение каталогов из

  • инфраструктура
    • ветви
    • теги
    • хобот
  • проект-для-клиент-1
    • ветви
    • теги
    • хобот
  • проект-для-клиент-2
    • ветви
    • теги
    • хобот

в

  • ветви
    • Функция-1
      • инфраструктура
      • проект-для-клиент-1
      • проект-для-клиент-2
  • теги
  • хобот
    • инфраструктура
    • проект-для-клиент-1
    • проект-для-клиент-2

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

Для работы с кодом, можно было бы просто оформить ствол и работать с этим. Тогда вам не нужны скрипты, которые проверяют все различные проекты. Они просто относятся к инфраструктуре с «../Infrastructure». Еще одна проблема с этой схемы является то, что вам нужно оформить несколько копий, если вы хотите работать над проектами совершенно независимо друг от друга. В противном случае изменение инфраструктуры для одного проекта может привести к еще один проект не компилировать, пока что не обновляются тоже.

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

Ответил 10/09/2009 в 14:13
источник пользователем

голоса
2

Да, это отстой. Мы делаем то же самое, но я не могу придумать лучший макет.

Итак, что мы имеем набор скриптов , которые могут автоматизировать все подрывные связаны. Проект каждого клиента будет содержать файл с именем project.list, которое содержит все подрывные проекты / путей , необходимых для создания этого клиента. Например:

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

Каждый сценарий, то выглядит примерно так:

for PROJ in $(cat project.list); do
    # execute commands here
done

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

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

Ответил 10/09/2009 в 13:56
источник пользователем

голоса
0

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

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

Ответил 10/09/2009 в 13:53
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more