Проект Talend в SVN

Ответ 1

Ну, "официальным" ответом является переход на Talend Integration Suite (TIS), который включает в себя интеграцию SVN. Это долгий путь для синхронизации действий нескольких разработчиков, использующих общий репозиторий.

Если TIS не является для вас вариантом, вы можете добиться успеха, поставив каталог проекта вашей Talend Open Studio (TOS) под управлением SVN. Это каталог сразу под "рабочим пространством", который имеет то же имя, что и ваш проект. Вам придется выполнять все операции SVN, такие как фиксация и обновление, вручную в этом каталоге, например, с использованием Tortoise (если вы находитесь в Windows). TOS может использовать этот проект, как если бы он не находился под SVN. Я лично не пробовал этого и рекомендовал бы использовать TIS вместо этого.

Ответ 2

Помещение рабочего пространства TOS под SVN категорически не рекомендуется, поскольку CSV/SVN в качестве основанного на файлах по своей природе, в то время как рабочее пространство TOS основано на каталогах. Вероятность того, что вы подвергаетесь повреждению рабочей области, очень высока.

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

Знайте! В подстроке * <workspace_root > /. Java * существуют внешние библиотеки и файлы классов для каждого задания в вашем проекте, выполненные как минимум один раз. Эти пути являются абсолютными. Это означает, что если вы планируете использовать рабочее пространство, контролируемое версиями, в общей среде, в команде необходимо разместить рабочую область в абсолютном местоположении в своей локальной файловой системе (например, c:/talend_git/workspace), В противном случае вы получите исключение класса, не найденное при выполнении заданий. Грустно, но это правда.

Ответ 3

Я объясню подход, который я придерживался

• Файлы, требуемые TOS IDE, - это файлы *.items и *.properties. Вы могут использовать эти файлы для версии, контролирующей ваши задания TOS, так как это будет поддерживать точное состояние рабочих мест в отношении IDE Talend.
• Итак, всякий раз, когда вы закончите некоторое улучшение в своей работе Talend. Экспорт используя опцию "Экспортировать элементы" и помещаем их под версию SVN. Файл как правило, является архивом ZIP-архива.
• Всякий раз, когда вам нужно вернуться к предыдущей версии, вы можете использовать "Импортировать элементы", параметры из архива ZIP-архива, который вы уже сохранили

То, как я работал с версиями рабочих мест Talend. Надеюсь, это поможет.

Ответ 4

Я думаю, что есть лучший механизм для этого с git и без отслеживания всего рабочего пространства. С несколькими разработчиками, отслеживающими всю рабочую область, возникают конфликты слияния для двоичных файлов и не масштабируются. Проверьте описанные здесь шаги - https://medium.com/@ganesh_m_r/version-control-talend-open-studio-project-b9523c48eb77. Дайте мне знать, если вы столкнулись с проблемами.

Ответ 5

Я столкнулся с аналогичной проблемой, написал блог об этом, см. Помещение проектов Talend Open Studio под контроль версий. В основном вы должны обновить всю рабочую область.

Ответ 6

Вместо того, чтобы хранить весь проект в SVN, вы можете экспортировать его содержимое и поместить его в свой SVN. (Мы делаем это, это хорошо работает для шоу одного человека или дисциплинированной команды.)

Плюсы:

• Вам не нужно совершать фиксацию из-за незначительных изменений, которые не влияют на сгенерированный исходный код.
• Вы сэкономите много места.
• У вас есть полный контроль над тем, что помещено в SVN, а что нет.
• Если вы отметили флажки "java sources" и "extract zip file", вы также получите исходный код открытого текста. Таким образом, вы можете использовать простые инструменты diff, чтобы увидеть то, что именно изменилось между вашими версиями.

Минусы:

• Вам нужно вручную импортировать новую версию в свою студию Talend, прежде чем приступить к какой-либо работе (если что-нибудь изменится) и вручную экспортировать ее перед фиксацией. Это может занять несколько минут для крупных проектов.
• Если кто-то забывает об этом, вы рискуете, что он работает со старым кодом и это совершает. (Эта ошибка может быть найдена при выполнении анализа diff в сгенерированном исходном коде перед фиксацией, но очень немногие люди делают это.)