Отдельные ветви Subversion для каждого языка программирования?

2

В некоторых проектах мне приходится иметь дело с более чем одним языком программирования (например, приложение графического интерфейса Delphi, которое взаимодействует с С# или Java-приложением). Репозиторий Subversion в настоящее время содержит три верхних ветки, по одному на каждый язык.

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

project1
  branches
  ...
  tags
  ... 
  trunk
    csharp_app
    delphi_app
    java_app
    ...
project2
...
Теги:
svn
repository
directory-structure

4 ответа

9
Лучший ответ

Поскольку эти отдельные субпроекты взаимодействуют, им необходимо перемещаться по стоп-стопу, и вам нужно пометить/разделить/разблокировать С#/Java/любые другие компоненты вместе. Если они не связаны друг с другом, я буду защищать (возможно) отдельные репозитории или отдельные каталоги в одном хранилище. Но не ветки или метки.

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

Я думаю, что язык программирования не имеет значения. Спросите себя, что у вас есть, и как вам нужно управлять этим. Я успешно это делал в прошлом с проектами, включающими Java и С++, и язык не является проблемой - он поддерживает синхронизируемые компоненты, которые вам нужно управлять.

Я бы не стал создавать новый каталог верхнего уровня для каждого языка. Что произойдет, если вашему компоненту Java вдруг потребуется слой JNI? Мне кажется, что реализация отражается в структуре каталогов верхнего уровня, и это не должно быть проблемой.

Поделиться
  • 0
    Да, я написал, что релизы взаимодействуют. Движение в ногу - это то, что мне нужно.
  • 0
    Ты сделал. Изменено соответствующим образом
3

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

Поделиться
  • 0
    «Тесная связь» лучше всего описывает то, чего я хотел бы достичь. +1
  • 0
    На самом деле «жесткая связь» - это плохо. см .: en.wikipedia.org/wiki/…
Показать ещё 1 комментарий
1

Да. Критерием является то, требуют ли приложения некоторой формы синхронизации своих функций друг от друга, и этот протокол связи (API, общий код, общие библиотеки) со временем может меняться. Если приложения не имеют ничего общего друг с другом, разделите репозитории. Наличие приложений, написанных на нескольких языках в репозитории, не имеет значения.

Поделиться
1

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

Поделиться
  • 0
    Какая часть может сломаться, вы имеете в виду процесс сборки проекта или миграцию на новый макет каталога?
  • 0
    Помещение вещей в разные стволы не приведет к их поломке. Я только имею в виду, что разные версии различных компонентов не будут работать вместе. Таким образом, версия 20 C # не будет работать с версией 5 java. И если вам нужно вернуться к версии 5, теперь вы должны вспомнить, какая версия C # работала с ним. Это может быть не очень легко. - но если все синхронизируется, это не проблема.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню