Fix version history

[josephjclark]

Short Description

• Ensure the new workflow_history from app state is tracked
• When checking out a project, write a forked_from map from each workflow into openfn.yaml
• When checking for divergence, ensure forked_from is the head of the workflow in the app (but only for workflows we've changed locally...
• ... and when merging, we only merge the workflows that have changed (just to be sure we don't revert anything)

Fixes #1231

List any considerations/cases/advice for testing/QA here.

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to know!):

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

[josephjclark]

So the deploy stuff seems to be working. Got a problem now where I'm getting conflicts every time I pull, even when tehre aren't conflicts (remote is ahead of local so we can just overwrite). This might be because I'm doing a generic merge - but like on deploy, the test is a little different to general merge test

Also I've messed the tests up but that's kind of anticipated - will fix soon

[josephjclark]

Bit of a revelation here after lunch.

if the provisioner is sending correct version histories, and if the version algorithm is the same in CLI and app - then we don't need forked from. The forked_from version should be at the head of each workflow history.

So if you check out a workflow, and generate the version hash for it, you know if the workflow has changed since the last fetch because the local version is not in the workflow history. You also know if the remote version is ahead of unchanged local because the local version is in the remote history, just not at the head.

If you check out locally and made an edit, the local version hash should be different to the head of history.

So I think we have all the information we need to make good decisions here, and shouldn't need to use the fork_version metadata.

Ah no that's not quite right:

• I checkout a branch
• I make a new change
• I now have a divergent local head and a history
• I fetch from the app
• How do I know if the app's history has diverged from my local history? Forked form gives me an anchor - I can see in the remote history where we were when we edited. If we don't have forked from, we know that local head and remote head are different, but we don't know the remote head changed since we checked out.

Phew. Complex. We do still need forked_version.

[josephjclark]

I've been thinking a lot about merge logic over the last couple of daysa and I'm worried I'm about to start building a lot into the CLI

I think really the Project package needs to support the different kinds of merge: like syncing a local to a remote is a pariticular strategy (we detect locally changed ones, merge those into the remote, and throw if there's any remote divergence in fetched from). That's different a general "merge all these workflows into that", which I don't think does any history checking.

I need to think about this more, but it's an extension of the merge mode thing I added for sandboxes/replace