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

Вы можете справиться с этим с помощью svn: externals. Это URL-адрес места в репозитории svn. Это позволяет вам извлекать части из другого репозитория (или того же самого). Один из способов использования этого - в проекте-для-клиента2, вы добавляете ссылку svn: externals на нужную ветку инфраструктуры, нужную ветку приложения 1 и т. Д. Таким образом, когда вы проверяете проект-для-клиента2, вы получаете все правильные штуки.

Ссылки svn: externals контролируются версиями вместе со всем остальным, поэтому, когда project-for-client1 помечается, разветвляется и обновляется, всегда будут втягиваться правильные внешние ветки.

Предлагается изменить макет каталога с

• Infrastructure
  • branches
  • теги
  • багажник
• project-for-client-1
  • branches
  • теги
  • багажник
• project-for-client-2
  • branches
  • теги
  • багажник

to

• branches
  • feature-1
    • Infrastructure
    • проект-для-клиента-1
    • проект-для-клиента-2
• теги
• trunk
  • Infrastructure
  • проект-для-клиента-1
  • проект-для-клиента-2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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