RFC 43 - Refactor Logs

[SeriousBug]

This is the discussions page for RFC 43.

This RFC was created to capture the discussions that spawned off in RFC 42 around how refactors affect downstream vaults.

[SeriousBug]

Here are a some of the discussion points raised in the previous RFC:

By @jonathanyeung:

Another related issue is with cross-vault refactoring. This works well today with Dendron when I own (or can edit) all vaults that depend on me. But what if I can't? If I have a published vault, how can I rename my note without potentially breaking reference links to that note in other people's vaults? Does this imply that we basically should always depend on a commit hash for a public vault?

In software, we can maintain back compat by guaranteeing an interface or an API. But here's where I think the analogy breaks down for us. What does 'guaranteeing' an interface mean for notes - that our note names and headers can never change? That's most likely going to be too restrictive - but maybe schemas can help us here.

By @kevinslin:

In terms of refactoring across multiple vaults, long term, the way we solve this is the same way that databases do: using a transaction log. Every time you perform a hierarchy mutating action, that action gets recorded in the transaction log. pseudo example below:

- ts: 2022-02-10 07:57: 
 action: rename
 inputs: foo.md
 output: bar.md
 data: ...

This transaction log is then consumed by downstream vaults and can be replayed so that the downstream vaults can catch up to the most recent state. There's actually prior work in this that we can also leverage: https://www.inkandswitch.com/cambria/

By @ScriptAutomate:

One last item: I think we've talked about a feature that we haven't yet implemented, and that is refactoring logs. As in, a machine-readable list of refactors in a repo. This is because cross-vault links are rather fragile right now, and break in the event that a refactoring is done on a vault outside of different workspaces. We'd likely want this as a feature request if there isn't one somewhere, but it could be designed with however this approach to vaults is implemented.

[SeriousBug]

Another use for refactor logs would be an Undo command. Dendron could undo the effects of a refactor in case the user did it accidentally.