You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you have a Language Forge project from an old model version (say 68), LfMerge will refuse to sync the project. But if the user has upgraded their project in FLEx and pushed an upgraded version, LfMerge will refuse to sync because it still sees the FLExProject.ModelVersion file in the local repo and says "Old model, not going to touch it" and bails out. We should probably change the logic to say "Old model, do a pull and see if there's a newer model available".
If LexBox adds an API to check the model version available on the server, then that could help: instead of doing a full Mercurial pull through LfMergeBridge which can take a while, it would be a single HTTP request to check the model number. So this might depend on sillsdev/languageforge-lexbox#1022 being completed and an API being built for that.
The text was updated successfully, but these errors were encountered:
Currently if you have a Language Forge project from an old model version (say 68), LfMerge will refuse to sync the project. But if the user has upgraded their project in FLEx and pushed an upgraded version, LfMerge will refuse to sync because it still sees the FLExProject.ModelVersion file in the local repo and says "Old model, not going to touch it" and bails out. We should probably change the logic to say "Old model, do a pull and see if there's a newer model available".
If LexBox adds an API to check the model version available on the server, then that could help: instead of doing a full Mercurial pull through LfMergeBridge which can take a while, it would be a single HTTP request to check the model number. So this might depend on sillsdev/languageforge-lexbox#1022 being completed and an API being built for that.
The text was updated successfully, but these errors were encountered: