Repo/Loom/Deck created one in their migrations, but CollabTopicAccept isn't
itself a topic, it's just a helper, so it needs to *find* the relevant
CollabTopicLocal rather than create a new one.
Both Git and Darcs are supported
- Darcs implementation applies right on the bare repo, I haven't tested to make
sure it works right (federated MR demo is going to be only for Git)
- Git implementation clones to temporary repo, runs `git am` on it to apply,
then pushes to the real bare repo (because `git am` doesn't work on bare
repos; I haven't tested yet to see how it handles conflicts; cloning and
pushing should be efficient since the refs are just hardlinked rather than
copied)
For now it's implemented only for Git:
If tracker is a local loom, and a (local or remote) origin repo is specified,
but no patches are provided, then generate them ourselves!
* Clone the (local) target repo
* Add the (local or remote) origin repo as a git remote
* Make sure target branch is an ancestor of the origin branch
* Generate patches for the commits that origin adds on top of target
* Insert them into our DB
In offerTicketC it can be used for fetching commits from the remote origin
repo, by knowing its clone URI
Only HTTP clone URIs are supported for now, because it's enough for finishing
the federated MR implementation. Apparently user@host:path isn't a valid URI
and I'll later add a parser for that
What's missing:
- Match patch VCS, origin repo VCS and target repo VCS
- Hook into postPersonInboxR
- If only origin is provided, generate patches / otherwise somehow remember the
commits proposed
RepoSourceR, for a repo that doesn't have a loom, lists looms that want to
serve that repo with buttons for bidirectionally linking the repo to a loom
Once linked, the repo navbar has a Patches/MRs link pointing to the LoomClothsR
of the linked Loom
Person inbox handler:
- Invite: Parse and insert to inbox
- Grant: Parse and insert to inbox
Repo/Deck/Loom inbox handler:
- Invite: Parse and remember as Collab record in DB for later
- Accept: Send a Grant (and remember it in DB)
Along with inviteC and acceptC, the Invite->Accept->Grant flow is now fully
federated, yay!
What's missing is UI for actually using it. Coming soon.
Giving access now starts with an Invite activity, followed by Accept from the
Invite's recipient. Finally, the resource sends a Grant, which is the actual
OCap.
I was going to link the matching Accept tables to them, but then switched to
the Invite-Accept-Grant model and going to implement it in the next patches. So
I'm committing these new tables just in case I decide to revert to the current
model.
