FrontierNav Weekly: 27th July 2020
Changes
- Open changes no longer conflict when a merge request created from it is approved.
- This is currently "experimental" until I've used it enough to be confident it covers any unforeseen real-world scenarios.
- Upgraded various project dependencies. This may or may not introduce problems with older browser versions, but it's a wait-and-see scenario.
Xenoblade Chronicles
- Fixed some map issues.
- e.g. Tephra Cave now uses the fully unlocked maps to avoid showing markers that look like they're in the middle of nowhere.
Work in Progress
- Improving Merge Request flow (read below)
Support the project
Thank you to this month's patrons!
Michael Rademakers, cd, Sebastian Tasto, Chuang Sing Kee, 777, Chad Bishop (ArlandSr), Aloftheabove, Roadrunnerto, Nightshade, Mario Carmona, Hex, Pussel W, yeili, Ghil and 2 anonymous patrons.
If you would like to support FrontierNav, please consider donating on Patreon. Doing so helps fund development and keeps the project going. Thank you.
Improving Merge Request Flow
As with last week, the focus is still on improving the Merge Request flow.
The change mentioned above around avoiding conflict messages when approving merge requests is a good step forward. This is typically known as conflict resolution. So whenever a "conflict" message appears, it'll definitely be a problem rather than a "maybe, maybe not" situation.
Most of the limitations that can cause conflicts with the current flow occur under complicated scenarios where multiple people are collaborating on the same subset of data. And since FrontierNav currently doesn't deal with those scenarios I can defer any related improvements later date.
However, to ensure that is actually the case, I've kept the new conflict resolution logic in an "experimental" state to make sure it doesn't run into any common real-world conflict scenarios that I might have missed in development. I'll probably fully release it in the coming weeks.
Next Up
Currently when sending multiple merge requests, each merge request will contain all of the changes from the previous merge request. That's a huge waste and it can be confusing. I've worked around this by rejecting merge requests that contain duplicate changes and leaving a "reason" message to avoid any misunderstandings. Not ideal.
To resolve this, I'll be implementing chained Merge Requests next. So rather than having subsequent merge requests duplicate the changes from the previous merge requests, they'll just point to them and FrontierNav will grab changes from those pointers if they haven't already been merged.
Thanks for reading.