For FME Server what are the practical differences between internal and remote Version Control? What considerations should we to take into account about when choosing between them?
Solved
Version Control - internal vs remote
+11- Supporter
Best answer by mattwilkie
Summary:
Internal version control is good for intermediate recovery but not for archival purposes. History is discarded when upgrading FME Server. The workaround is to manually download any historical versions that may be especially important to keep.
Remote version control only works with Github. So you can't for example use your own on-premise Gitlab or Gitea server, or even a git folder on the server machine.
I'll keep this summary post updated over time, wiki style.
+11- Supporter
One obvious consideration I see from the doc page is that when using internal VC the history is lost when upgrading server. But that could be worked around by copying the repo folder(s) on the server somewhere else before upgrading , yes?
(That doc page is kind of confusing. It starts off with the phrase "upload (from FME Server) ... a new or existing file". How does one upload anything from Server? Users download from and upload to Server, right? Additionally there are several uses the word "local" throughout. Is it talking about local to the FME Desktop or local to the Server? (or local to the repo?))
mattwilkie wrote:
One obvious consideration I see from the doc page is that when using internal VC the history is lost when upgrading server. But that could be worked around by copying the repo folder(s) on the server somewhere else before upgrading , yes?
(That doc page is kind of confusing. It starts off with the phrase "upload (from FME Server) ... a new or existing file". How does one upload anything from Server? Users download from and upload to Server, right? Additionally there are several uses the word "local" throughout. Is it talking about local to the FME Desktop or local to the Server? (or local to the repo?))
There's something wrong with the link above, it goes to the wrong place.
https://docs.safe.com/fme/html/FME_Server_Documentation/WebUI/Version-Control.htm
Other than that I agree.
+11- Supporter
david_r wrote:
There's something wrong with the link above, it goes to the wrong place.
https://docs.safe.com/fme/html/FME_Server_Documentation/WebUI/Version-Control.htm
Other than that I agree.
link fixed, thanks. the editor seems to not like https prefaced links.
+11- Supporter
mattwilkie wrote:
One obvious consideration I see from the doc page is that when using internal VC the history is lost when upgrading server. But that could be worked around by copying the repo folder(s) on the server somewhere else before upgrading , yes?
(That doc page is kind of confusing. It starts off with the phrase "upload (from FME Server) ... a new or existing file". How does one upload anything from Server? Users download from and upload to Server, right? Additionally there are several uses the word "local" throughout. Is it talking about local to the FME Desktop or local to the Server? (or local to the repo?))
"that could be worked around by copying the repo folder(s) on the server somewhere else before upgrading"
No. There is no repo folder to copy as it's stored in the database. So at this time it appears the workaround is to manually download any historical versions that may be especially important to keep. In other words the internal version control is good for intermediate recovery but not for archival purposes.
mattwilkie wrote:
"that could be worked around by copying the repo folder(s) on the server somewhere else before upgrading"
No. There is no repo folder to copy as it's stored in the database. So at this time it appears the workaround is to manually download any historical versions that may be especially important to keep. In other words the internal version control is good for intermediate recovery but not for archival purposes.
Where did you find that quote? I can't find it on the page linked above. However, I see the following bit, which makes more sense with regard to your findings:
[...] the restored FME Server does not maintain version history. However, if you push your file versions to a remote Git repository, you maintain backups of them outside of FME Server.
That said, I agree that it's a fairly major limitation that local versions cannot be preserved when upgrading FME Server. Not everybody is working with installations where using Github is an option.
+11- Supporter
mattwilkie wrote:
"that could be worked around by copying the repo folder(s) on the server somewhere else before upgrading"
No. There is no repo folder to copy as it's stored in the database. So at this time it appears the workaround is to manually download any historical versions that may be especially important to keep. In other words the internal version control is good for intermediate recovery but not for archival purposes.
Oh, hah! I'm quoting myself. I made that speculation/assertion in the <strike>opening post</strike> my first response.
+11- Supporter
- Best Answer
Summary:
Internal version control is good for intermediate recovery but not for archival purposes. History is discarded when upgrading FME Server. The workaround is to manually download any historical versions that may be especially important to keep.
Remote version control only works with Github. So you can't for example use your own on-premise Gitlab or Gitea server, or even a git folder on the server machine.
I'll keep this summary post updated over time, wiki style.
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.