Allow GIT or Subversion to be used as a revision controlled repository for workspaces, and Workbench interacts directly with that system when saving workspaces.
Released
Workbench connects directly to revision control
- skung
- matthieuc
- quince
- rylanatsafe
- gerhardatsafe
- yldbooysen
- hollyatsafe
- siennaatsafe
- nathanatsafe
- fmelizard
- david_r
- nielsgerrits
- redgeographics
- virtualcitymatt
- hkingsbury
- danilo_fme
- caracadrian
- erik_jan
- lifalin2016
- sigtill
- asadamjad
- warrendev
- tcrossman
- deanhowell
- j.botterill
- carmijo
- tomf
- runneals
- stalknecht
- joy
- fgiron
- dbaldacchino1
- mattwilkie
- nic_ran
- jelle
- geosander
- kennyo
- mgg_beca
- martinkoch
- annette2
- mark_f
- jackyd
- canerakin
- arthur_bazin
- cory
- ciarab
- stefanh
- jeroenstiers
- matthieuv
- juanmahere
- smol
- revesz
- fmeuser_gc
- mikael_sweco
- richsnyder0
- drimbles
- jamess
- timmorrissey
- andrej
- marko
- ssiegl
- gschleusner
- kaylin.austin
- northswejohan
- adieporter
- makt
- sam_a
- jesidas
- davidvandalen2
- ewoudvdc
- princebilliam
- chenderson
- sybold
- thibaut_gheysen
- rsmith
- ml56067
- geobaehr
- raean
- danielbarber
- jlmiserez_inser
- guy_lafleur
- luke.giles
- jonathan
- erooen
- matthewbrucker
- lindsay
- rjcragg
- geolassi
- zander
- andrewbnz
- friesewoudloper
- littlefictions
- jarrydhunter
- maryse_bucking
- jvbmov
- singletrackmap
- john_otoole
- cwarren
- paulbrandt73
- simonl
- woody
- iew
- jiranek_hsro
- hsamor
- dfresh
- susannebell
- schwerjo
- steinm
- wizdatawizard
- robclark984
- annabayona
- offermann82
- geobroetchen
- inba
- mygis
- yongjie
- alexandreroy
- kam
- daniel.egger
- julien
- patrick_koning
- gagankc
- camtemple
- majid9
- mattia.deago
- brianw_os
- ecthelion
- maayke
- ekkischeffler
- hermann
- geogaard
- magi
- paalpedersen
- marnickcle
- skime
- roland.martin
- mferwerda1111
- danielkroon
- tva
- cfvonner
- ngstoke
- kalbert
- neilhellas
- tara_he
- gavinpark
- darkspatiallord
- jeroen
- jneujens
- michpil
- anari
- herfried
- giosp
- rileym
- johnglick
- tim.rastall1
- geoportalcartog
- adriano
- janb
- geoal
- jpvo
- dellerbeck
- wicki
- jorge_vidinha
- g_karssenberg
- michaelpascoe
- jsdbroughton
- _fabian_
- jeand
- kweller
- phoeffler
- soeren
- morteneines
- mkurowski
- lam91
- hdlobb
- henrik_thoren_
- solovyev
- ville
- danilovic
- damiati
- jeffhobbs
- mikedlong
- mikmansson
- richardsnyder3
- toddburciaga
- bbor
- kasiponnapalli
- turid_skedsmo
- mathieu_ambrosy
- glagolicmiso
- mchauvet
- alexanderyanush
- xuhengx
- keplerleee
- tom_colley
- jeff_konnen
- jatwood
- matthewphillips
- lpalli
- pelbe3
- arielwin
- josefarv100
- mferwerda
- battlezone77
- victor.r
- pharaon
- thezedman
- liesbethdegroot
- robbycattoor
- willyb
- jsidborn
- andrejacquet
- ravenatsafe
- whit
- guha
- dagw
- samuelvaldez
- danielwortham
- mikkok
- lundopendata
- goulartajg
- fmserverlund
- DanAtSafe
- laurawatsafe
This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+17- Contributor
Awesome idea. I'm using GIT for revision control on most of my workbench files, so not having to drop out and use CLI or TortoiseGIT would be nice.
+24- Contributor
When you have 2 users working on the same workspace on different computers on FME Desktop and then connect to an FME Server or FME Cloud you are bound to have one person overwriting the other workspace. Integrating FME Server AND FME Desktop for each user towards for instance git would make it possible to NOT use the upload to FME Server function with FME - but "auto sync" files to/from github - and make FME Server "listen" to these changes and always use the last version from github. Not sure if I explained that well enough. This would also be great for accompanying files (textfiles, schemamapping, readers, static inputdata etc).One thing that might be an issue would be linking to c:\\data\\myschemamapper.xlsx on a local computer - while this have to automatically re-map to c:\\apps\\fmeserver\\......\\data\\myschemamapper.xlsxl on FME Server - without changing the published/private parameter
+10This suggestion combined with the Internet as a Filesystem Proposal (
https://trello.com/c/Lmllldpo) and off course GitHub added as a FileSystem could do the trick!
+17- Contributor
After tonight's FME 2016 Sneak Peek presentation to the Denver FME Users Group, a strong appeal to do this was made. Git was asked for as the first revision control system we should integrate with.
It may be worth seeking a larger sample of feedback for which service to do first. I'd be more partial to SVN rather than a distributed system like GIT.
+7Late reply, but I would also like this! Furthermore, I think it could be very useful if an FME Engine on a virtual machine could pull the latest desired Git branch once it has fired up. That way, publishing a workspace from Desktop to Server basically becomes obsolete. You would then probably need to config FME Server so that it pulls the necessary workspaces automatically from Git, for instance.
I would add the following ideas to this productive discussion:
- Use a plug-in architecture (like the Eclipse IDE) to accommodate multiple products (Mercurial).
- Provide plug-in-specific menus, this screenshot is from Eclipse/Mercurial:
'
- Support this in both Desktop and Server.
- I have not thought this through but I would use this for workspaces (and accompanying artifacts), custom transformers, and maybe more.
- I have spoken with Aaron Koning about this one, I would also like to version Server's configuration files.
+16- Contributor
In addition to being able to connect to revision control it would be fantastic if workspaces could be deployed, or somehow otherwise linked, directly from revision control to FME Server.
+5I posted something similar, although not as well worded!
https://knowledge.safe.com/content/idea/21925/fme-...
We have a staging and live environment and keeping tabs on each version can be a headache. I was thinking the server could automatically create a new version number/date that isn't the service name but kept as metadata. A testing area within FME server and then deploy live would be great as well as auto back ups and versioning. Even better, drag and drop between in testing to live which auto backup and logs version info as well as which user made the changes.
- Safer
For FME 2017.0 it is looking more and more like a "Github/Git" backend for FME Server is going to happen. Had good meeting with FME Server team. Will keep you all posted as we will want feedback as this progresses. Idea is that all the workspaces etc. would be versioned in Git when published etc. Dale and I also discussed the possibility of "fme workgroup" model where there is a essentially and FME Server core/repository that is part of fme desktop deployment to promote and act as single place for all workspaces to be stored. Gives a natural way for organizations to also migrate to server.
- Safer
I got it and it makes total sense. See my comment. That is exactly one of the things that the github backend would do for you on FME Server.
+28- Contributor
I would like to suggest that the development team consider the ability to integrate with GitHub Enterprise for those of use behind heavy firewalls.
+1- Contributor
I would choose teamfoundationserver just because of the fact that git doesn't seem to be able to merge workspaces verry well. But of course a sourcecontroll system would be verry usefull.
+8- Contributor
This is great, but we would still need some way to merge changes to the same workspace or transformer from different branches, as sync timing and interpretation can't be guaranteed. As is, I couldn't imagining even attempting to merge such files if a merge conflict arises, as interpreting the raw text would be an impractical eye-gouging experience.
+5Sounds really promising will save a lot of versioning head aches. One thing I would love to see is a modular system. Say I have a bunch of transformers that read, clip and organise the data within a bookmark, I'd like to be able to save that as a module and push that up to the server. The server then automatically pushes that module change to all workbenches that have it. It can be a pain to go through every workbench and repeat the same changes.
+11- Safer
While this hasn’t been added directly into Workbench, we have added support for Version Control to FME Server for 2017.1. With this, it would be possible to upload your workspaces to FME Server and use it to keep track of your workspace versions.
This idea: https://knowledge.safe.com/idea/51410/version-control-in-fme-server-next-steps.html contains a video of how to work with FME Server Version Control and what to do if you don’t already have FME Server. If you’re interested, please try it out and give us your feedback through the idea.
+17- Contributor
Hi Everyone, thank you all for your comments on this Idea! After reading all of your comments, it has got me thinking… what functionality would you like to see as part of revision control? Is there anything that you wouldn’t want compare? Are there features or items that a must for a successful revision control in your environment?
Please add comments to my post here for what your ideal revision control would (or would not) have as part of its functionality.@patrick_koning, @marko, @nic_ran, @samuelvaldez, @julien, @jeffhobbs, @david_r, @lars_de_vries, @sigtill, @kweller, @cfvonner_inacti+24- Contributor
I think the key would be to at least have it behave like FME Server 2018 where you can store different versions of your workspace. This is how we use FME and GitHub right now. We simply commit the latest version of the workspace. It allows us to roll the workspace back if absolutely needed and we don't have a backup somewhere else.
To me though, the ideal answer would be to have two different people work on one workspace and then be able to merge the workspaces into the production workspace. This would allow for co-editing for a single workspace which is important when you're trying to make use FME as a core for an integration between different system e.g. ERP and asset management.
I can't think of anything that I wouldn't want to compare.
+17- Contributor
Thanks @jeffshobbs! What about things that might be more cosmetic (i.e.- transformer positioning) or more metadata-like (bookmarks, annotations, etc.)? I imagine that annotations would be useful to keep or review prior to merging.
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.