Progetto Talend in SVN

Question

Ho bisogno di usare Talend Open Studio con un SVN. Qual è la cartella che dovrei inserire nel repository?

Answer 1

Bene, la risposta "ufficiale" è l'aggiornamento a Talend Integration Suite (TIS), che include l'integrazione SVN. Fa molto per sincronizzare le attività di diversi sviluppatori che utilizzano un repository condiviso.

Se TIS non è un'opzione per te, potresti avere un certo successo inserendo la directory del progetto del tuo Talend Open Studio (TOS) sotto controllo SVN. Questa è la directory immediatamente sotto "workspace" che ha lo stesso nome del tuo progetto. Dovresti eseguire tutte le operazioni SVN, come commit e update, manualmente su questa directory, ad esempio usando Tortoise (se sei su Windows). TOS potrebbe essere in grado di utilizzare questo progetto come se non fosse sotto SVN. Personalmente non l'ho provato, e raccomanderei l'uso di TIS.

Answer 2

Ho affrontato un problema simile e ne ho scritto un blog, vedere Putting Talend Open Studio projects under version control. Fondamentalmente dovresti eseguire la versione dell'intero spazio di lavoro.

Answer 3

spiegherò l'approccio che ho seguito

• I file richiesti da TOS IDE sono *.items e *.properties file. L'utente può utilizzare questi file per la versione che controlla i propri lavori TOS in quanto sarà mantenere lo stato esatto dei lavori rispetto a Talend IDE.
• Così ogni volta che hai finito con qualche miglioramento nel tuo lavoro Talend. Esportalo con usando l'opzione "Esporta elementi" e inseriscili sotto la revisione SVN. Il file generato sarà in genere un file di archivio ZIP.
• Ogni volta che è necessario per ripristinare una precedente revisione è possibile utilizzare la funzione "Importa Items" opzioni da un file di archivio ZIP avete già salvato

Ecco come ho lavorato con delle versioni di posti di lavoro Talend. Spero che questo ti aiuti.

Answer 4

L'inserimento di uno spazio di lavoro TOS in SVN è fortemente sconsigliato, poiché CSV/SVN è basato su file per natura mentre lo spazio di lavoro TOS è basato su directory. La probabilità di incorrere nella corruzione dello spazio di lavoro è molto alta.

Tuttavia ho ottenuto buoni risultati inserendo sotto git, invece (dai un'occhiata a here per un'idea). Devo dire che non è elegante e mettere sotto controllo di versione l'intero spazio di lavoro è un enorme spreco di spazio (si impegnano a compilare file, log, cronologia, temp ...), ma è l'unica soluzione sicura per l'integrità dei metadati.

Attenzione! Nella sottostruttura workspace_root > /.java* nella sottostruttura * < ci sono librerie esterne e file del percorso di classe per ogni lavoro nel progetto eseguito almeno una volta. Questi percorsi sono assoluti. Ciò significa che se si prevede di utilizzare l'area di lavoro controllata dalla versione in un ambiente condiviso, chiunque nel team deve collocare l'area di lavoro nella posizione assoluta nel proprio file system locale (ad esempio c:/talend_git/workspace). Altrimenti si otterrà una classe che non trova eccezioni al momento dell'esecuzione dei lavori. Triste ma vero.

Answer 5

Penso che ci sia un meccanismo migliore per farlo con git e senza tracciare l'intero spazio di lavoro. Con più sviluppatori che tracciano l'intero spazio di lavoro danno conflitti di unione sui file binari e non vengono ridimensionati. Controlla i passaggi menzionati qui - https://medium.com/@ganesh_m_r/version-control-talend-open-studio-project-b9523c48eb77. Fammi sapere se affronti problemi.

Answer 6

Invece di memorizzare l'intero progetto nel SVN, è possibile esportarne il contenuto e inserire la compilazione nel SVN. (Lo facciamo, funziona bene per una mostra personale o una squadra disciplinata.)

Pro:

• non avrete bisogno di fare un commit a causa di modifiche minori che non influenzano il generati codice sorgente.
• Si risparmia molto spazio.
• Hai il controllo completo di ciò che viene messo in SVN e cosa no.
• Se hai spuntato le caselle di controllo "java sources" e "estrai il file zip", riceverai anche il codice sorgente in chiaro. Quindi puoi utilizzare semplici strumenti diff per vedere quale esattamente cambiato tra le tue revisioni.

Contro:

• È necessario importare manualmente nuova revisione nel vostro studio Talend prima di iniziare qualsiasi lavoro (se mai cambiato), e manualmente esportarlo prima del commit. Questo potrebbe richiedere diversi minuti per progetti di grandi dimensioni.
• Se qualcuno si dimentica di farlo, rischi di lavorare con il vecchio codice e lo impegna. (Questo errore può essere riscontrato quando si esegue una revisione del diff sul codice sorgente generato prima del commit, ma pochissime persone lo fanno.)