3 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	275ddd76e8	Keep rollouts and the merges they answer in the rollouts bucket (issue 1092) ... Once chain_moved records the kind, a plan is a key of the rollouts bucket under its id and the open batch is the same key in state assembling. A save refuses a copy another save moved since (the plan's own Revision, kept in its value, counts saves) and keeps the merges the record holds, so a copy read before a merge moved cannot lay it back. The merges a batch or walk answers are the record's held field, with the columns the table had; a merge no plan answers stays, flagged, in the record that held it last, or in the record kept for those. A merge moved to a plan is written to the receiving record first and then taken from the giving one; one found in both is read from the one it entered last and repaired at the next cut. Plans and merges are read from a view kept by one watch of the bucket. A bus that does not answer, a lease lost and a key moved are now not-now like the store being away, so a merge whose plan could not be written is held and handed over again, never acknowledged. The start moves release_plan and batched_merge into the bucket, one kind, counted against both tables.	2026-10-18 03:06:50 +02:00
jschoubben	66dc501fc4	Split the unit level from the integration level in cmd, builder, link, catalogue, inventory; cheap fixtures for the archive-entry bound, the registry waits and the catalogue copy (issue 895)	2026-10-17 21:32:23 +02:00
jochen	e9f060e0be	Read a plan by its id as a parameter, never as SQL (issue 561) ... PlanByID pasted its id into the query, and the id comes from a caller of the plans verb: an id holding a quote changed the query (x' or '1'='1 answered another plan). The id is now $1, and RecentPlans's limit too, so no plan query is built from a value.	2026-10-12 16:33:23 +02:00