Управление Java-упаковкой API C ++ для использования графическим интерфейсом Java: правильный контроль версий
У нас есть большой проект, состоящий из следующего:
- A: C ++ исходный код / библиотеки
- B: Java и Python упаковка библиотек C ++, используя SWIG
- C: GUI, написанный на Java, который зависит от Java API / wrapping.
Люди используют проект всеми возможными способами:
- C ++ проекты, использующие C ++ API
- Java-проекты с использованием Java API
- Скрипты Python
- Сценарии MATLAB (с использованием Java API)
- через графический интерфейс Java
В настоящее время A, B и C находятся в одном хранилище Subversion. Мы переходим на Git / GitHub, поэтому у нас есть возможность реорганизоваться. Мы думаем о разделении A, B и C на их собственные репозитории. Это вызывает у нас несколько вопросов:
- Имеет ли смысл разделять SWIG-упаковку Java и Python (то есть файлы интерфейса (* .i)) в отдельный репозиторий?
- В настоящее время генерируемые SWIG файлы .java выводятся в исходном дереве графического интерфейса и отслеживаются в SVN. Поскольку мы не хотим отслеживать файлы, сгенерированные машиной, в наших репозиториях git, каков наилучший способ сохранения зависимости графического интерфейса от файлов .java / .jar, сгенерированных SWIG? Подумайте над этим: если новый разработчик хочет создать графический интерфейс Java, ему не нужно создавать A и B с нуля; они должны иметь возможность получить копию C, из которой они могут немедленно построить графический интерфейс.
- Управление версиями: когда все находится в одном репозитории, A, B и C обязательно соответствуют друг другу. Когда у нас есть разные репозитории, графический интерфейс должен работать с известной версией обертки, а обертка должна работать с известной версией API C ++. Каков наилучший способ справиться с этим?
Мы глубоко задумывались над каждым из этих вопросов, но хотим услышать, как сообщество подойдет к этим вопросам. Возможно, git submodule / subtree является частью решения некоторых из них? Мы не использовали ни один из них, и кажется, что субмодули вызывают у людей головную боль. У кого-нибудь есть истории успеха с любым из них?
Решение
Хорошо, я выглядел в похожей проблеме, как вы (несколько взаимодействующих проектов), и я попробовал три возможности subtree, submodules и один простой репозиторий с несколькими папками, содержащими отдельные части. Если есть больше / лучшие решения, я не знаю о них.
Короче говоря, я пошел на один репозиторий, но это может быть не лучшим решением в вашем случае, это зависит …
- Преимущество
submodulesв том, что он позволяет легко управлять, так как каждая часть сама является репо. Таким образом, отдельные стороны могут работать только над своим репо, а другие части могут быть добавлены из предопределенных бинарных выпусков / … (как вам угодно). Вы должны добавить дополнительное репо, которое объединяет отдельные репо вместе.
Это является как преимуществом, так и недостатком: каждый коммит в этом репо определяет рабочую конфигурацию. В идеале ваши разработчики должны будут сделать каждый коммит дважды — один для «рабочего репо» (от A до C) и один для репозитория конфигурации.
Так что этот метод может хорошо подойти, если вы намерены, чтобы части A-C были в основном независимыми и не менялись слишком часто (это только для новых выпусков). - Я должен признаться, что мне не понравилось
subtreeметод лично. Для меня (лично) синтаксис кажется неуклюжим, и выгода не слишком велика.
Преимущество заключается в том, что удаленные модификации легко извлекаются и вставляются, но вы теряете удаленную историю. Таким образом, вы должны избегать вмешательства в удаленную разработку.
Это обратная сторона: если вы собираетесь вносить изменения в детали, вам всегда нужно беспокоиться об истории. Конечно, вы можете просто разработать в git remote и для тестирования / объединения / интеграции изменений вmasterветка. Это нормально в основном для чтения удаленных репозиториев (если я занимаюсь разработкой только на A, но мне нужны B и C), но не для регулярных модификаций (в примере для A). - Последняя возможность — одно простое репо с папками для каждой части. Преимущество заключается в том, что не требуется непосредственно администрирование для синхронизации частей. Однако вы не сможете гарантировать, что каждый коммит будет запущен. Также вам, разработчикам, придется делать администрирование вручную.
Вы видите, что выбор зависит от того, насколько близко отдельные части A-C связаны между собой. Здесь я могу только догадываться:
Если вы находитесь на более ранней стадии разработки, где изменения во всем дереве исходного кода являются общими, то одно большое репо лучше обрабатывается, чем разделенная версия. Если ваши интерфейсы в основном постоянны, разделение позволяет делать небольшие репо и более строгое разделение вещей.
Код SWIG и код C ++ кажутся довольно близкими. Таким образом, разделение этих двух элементов кажется менее практичным, чем разделение GUI от остальных (на мой взгляд).
Для вас другой вопрос «Как обращаться с новыми разработчиками / (не) отслеживая машинно-сгенерированный код?»:
Сколько коммитов сделано / требуется (только релизы или каждый отдельный коммит)? Если интересны только релизы, вы можете использовать бинарные пакеты. Если вы намереваетесь совместно использовать каждый отдельный коммит, вам придется предоставить много разных двоичных версий. Здесь я хотел бы предложить, чтобы они скомпилировали все дерево один раз, потратив несколько минут, а оттуда восстановление занимает всего несколько минут. make это не должно занять слишком много времени. Это можно даже автоматизировать с помощью хуков.
Другие решения
Других решений пока нет …