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- Enthusiast
- 92 replies
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.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, 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 an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, 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.
+11- Enthusiast
- 92 replies
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?))
- 8394 replies
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- Enthusiast
- 92 replies
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- Enthusiast
- 92 replies
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.
- 8394 replies
"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- Enthusiast
- 92 replies
"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- Enthusiast
- 92 replies
- 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.