At the moment patches are stored a tags with the radicle-patch/ prefix. Instead, we want to store patches in the event log by publishing a patch creation event.
Event specification
When a peer creates a patch, they publish a patch.create event. The event contains the title, the description, and the commit ID that should be merged. The event is published to the topic patch/<peer-id>/<patch name>. Here <peer-id> is the peer ID of the patch creator and <patch name> is a name chosen by the peer. A patch is only valid if its event log starts with a patch.create event published by the peer that matches the topic. Choosing the patch name is up to the tooling. Initially, we’ll continue to use the branch name so we can easily match branches and patches.
The author of an event can update a patch by publishing a patch.update to the patch’s topic. The update event may contain a new title, a new description, and a new commit ID.
Change-set reference and replication
When the event log for a patch is replicated by a peer the peer should also replicate the commit that holds the patch’s changes. In addition, this commit must have a reference in the monorepo so that working copies can fetch it and check it out.
One way to accomplish this is to have references to patch commits in the monorepo. This is similar to the current patch implement. But instead of referencing an annotated tag the reference just points to the commit.
With this approach an update to the changes will also update the reference and as a result the previous change sets will not be available after a force-push. We can tackle this in the future by keeping references for each patch version around.
I don’t see any suitable alternatives to this approach.
Implementation
upstream patch create will publish a patch creation event
upstream patch update will publish a patch update event
upstream patch fetch needs to be updated to create the correct references
In the GUI, patches will be listed by iterating over all patch topics of a project and looking for the patch creation events. (We need to decide whether we provide a dedicated endpoint for this or whether we aggregate this all in the frontend)
At the moment patches are stored a tags with the
radicle-patch/prefix. Instead, we want to store patches in the event log by publishing a patch creation event.Event specification
When a peer creates a patch, they publish a
patch.createevent. The event contains the title, the description, and the commit ID that should be merged. The event is published to the topicpatch/<peer-id>/<patch name>. Here<peer-id>is the peer ID of the patch creator and<patch name>is a name chosen by the peer. A patch is only valid if its event log starts with apatch.createevent published by the peer that matches the topic. Choosing the patch name is up to the tooling. Initially, we’ll continue to use the branch name so we can easily match branches and patches.The author of an event can update a patch by publishing a
patch.updateto the patch’s topic. The update event may contain a new title, a new description, and a new commit ID.Change-set reference and replication
When the event log for a patch is replicated by a peer the peer should also replicate the commit that holds the patch’s changes. In addition, this commit must have a reference in the monorepo so that working copies can fetch it and check it out.
One way to accomplish this is to have references to patch commits in the monorepo. This is similar to the current patch implement. But instead of referencing an annotated tag the reference just points to the commit.
With this approach an update to the changes will also update the reference and as a result the previous change sets will not be available after a force-push. We can tackle this in the future by keeping references for each patch version around.
I don’t see any suitable alternatives to this approach.
Implementation
upstream patch createwill publish a patch creation eventupstream patch updatewill publish a patch update eventupstream patch fetchneeds to be updated to create the correct references