Well, the "official" answer is to upgrade to Talend Integration Suite (TIS), which includes SVN integration. It goes a long way to synchronizing the activities of several developers using a shared repository.

If TIS is not an option for you, you might have some success by putting the project directory of your Talend Open Studio (TOS) under SVN control. This is the directory immediately under "workspace" that has the same name as your project. You would have to perform all SVN operations, such as commit and update, manually on this directory, for example using Tortoise (if you re on Windows). TOS might be able to use this project as if it was not under SVN. I personally haven t tried this, and would recommend using TIS instead.

Putting a TOS workspace under SVN is strongly discouraged, as CSV/SVN as file-based by nature while TOS workspace is directory-based. The probability that you incur in workspace corruption are very high.

However I achieved good results putting in under git, instead (have a look here for an idea). I must say it s not elegant and putting the entire workspace under version control is a tremendous waste of space (you will commit compiled files, logs, history, temp...), but it s the only safe solution for your metadata integrity.

Be aware! In *<workspace_root>/.java* subtree there are external libraries and the classpath files for each job in your project you executed at least one time. These paths are absolute. This mean that if you plan to use your version-controlled workspace in a shared environment anyone in team must place the workspace in the absolute location in their local file system (ie. c:/talend_git/workspace). Otherwise you ll get a class not found exception upon executing jobs. Sad but true.

I will explain the approach I have followed

• The files required by TOS IDE are *.items and *.properties files. You can use these files for version controlling your TOS jobs as it will maintain exact state of jobs with respect to Talend IDE.
• So whenever you are finished with some enhancement in your Talend job. Export it using "Export Items" option and put them under SVN revision. The file generated will be usually a ZIP archive file.
• Whenever you need to revert back to a previous revision you can use the "Import Items" options from a ZIP archive file you have already saved

That s how I have worked with versioning of Talend jobs. Hope this helps.

I think there is better mechanism to do this with git and without tracking entire workspace. With multiple developers tracking entire workspace gives merge conflicts on binaries and does not scale. Check the steps mentioned here - https://medium.com/@ganesh_m_r/version-control-talend-open-studio-project-b9523c48eb77 . Let me know if you face issues.

I faced a similar issue an wrote a blog about it, see Putting Talend Open Studio projects under version control. Basically you should version your entire workspace.

Instead of storing the whole project in your SVN, you can export its content and put the build into your SVN. (We do this, it works well for one man show or a disciplined team.)

Pros:

• You won t need to make a commit because of minor changes that don t affect the generated source code.
• You will save a lot of space.
• You have complete control of what is put to SVN and what is not.
• If you ticked the "java sources" and "extract the zip file" checkboxes, you will also get plaintext source code. So you can use simple diff tools to see what exactly changed between your revisions.

Cons:

• You have to manually import new revision into your Talend studio before you start any work (if anything changed), and manually export it before the commit. This may take several minutes for large projects.
• If anyone forgets to do that, you risk that he works with old code and commits that. (That mistake can be found when doing a diff review on the generated source code before commit, but very few people do that.)