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?
Best answer by mattwilkie
View original
+8
- Contributor
- 67 replies
-
8 October 2020
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?))
Userlevel 4
- 8177 replies
-
9 October 2020
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.
+8
- Contributor
- 67 replies
-
9 October 2020
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.
+8
- Contributor
- 67 replies
-
5 February 2021
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.
Userlevel 4
- 8177 replies
-
8 February 2021
"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.
+8
- Contributor
- 67 replies
-
9 February 2021
"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.
+8
- Contributor
- 67 replies
-
1 December 2022
- 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
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.