transaction

SOW 0.4.0 保留了原生 filesystem 与 r2 发布后端。早期提案曾计划使用 rclone，并增加远端审计和预览命令。 最终选择原生后端，是因为 SOW 需要逐项记录条件写入及其结果。 当前命令语法见 sow publish。 为什么保留原生后端 发布计划为每个文件记录预期 SHA-256 和操作。后端需要创建不可变对象，避免覆盖已有内容，并按条件更新可变入口文件。 SOW 记录操作结果，用于中断后继续发布。 批量复制工具需要额外的身份与检查点模型才能保留这些规则。0.4 选择 …

SOW 0.3.0 减少了重复包读取与数据库查询。Plain 生成只遍历一次包内容；Managed 构建缓存已解析的包数据，并批量提交新包池文件。本版还移除了已退役的运行时与发布代码。 Plain：每个软件包只读一次 默认不签名的 sow create 流程对每个 RPM 或 DEB 只做一次哈希与解析，--jobs 控制并行任务数。SOW 根据解析结果生成元数据，写入索引前再次检查软件包集合与文件属性是否变化。 Plain 构建中断后，从软件包目录重新运行即可。0.3 移除了 Plain 的操 …

构建生成本地快照（Generation）。发布把快照中的文件上传到目标，并记录进度，以便中断后继续。 每个目标分别保存检查点，记录上次完成发布的内容。 状态归属 Repository 记录 目标记录 软件包、Desired 状态与 Built 状态 发布尝试与检查点 Generation 与变更集 远端清单 保留的包和元数据引用 宽限期与删除记录 发布顺序 固定发布计划 -> 上传包体 -> 上传不可变元数据 -> 记录提交意图 -> 按视图逐一更新协议入口文件 -> 校验存储与公共 URL …

用 status 查看状态，check 校验仓库，changes 查看文件变化，log 读取操作历史。 命令 回答的问题 status 是否需要构建或恢复？是否有写者活动？ check 状态、包字节、索引、签名是否一致且可以交付？ changes 两个构建快照之间有哪些本地文件变化？ log 执行了哪些操作，改变了什么？ retain ls 显式保留了哪些构建快照？ 这些命令不修改仓库内容。 查看状态 sow status -r demo 结果包含期望状态修订号、构建快照、脏 Dist、待构建包 …

Managed 模式先记录变更，再应用变更。中断后，SOW 根据记录完成或回滚操作。 应使用哪个命令恢复，取决于中断的操作。 恢复中断操作 先查看记录的状态： sow status -r demo sow log -r demo 状态 下一步 clean 交付前运行 sow check dirty 运行 sow build，应用待构建的成员或配置变化 recovering 按下表选择与中断操作对应的恢复命令 error 根据诊断与日志检查报错文件或操作 中断操作 恢复命令 …

设计归档解释 SOW 在仓库布局、状态模型和发布流程上的选择。 文章日期记录决策成文时间，修改日期记录后续修订。 了解当前设计，可以从以下文章开始： 系统模型：软件包、发行版、构建快照与发布目标。 一棵包体树：为什么多个视图共用包池。 发布与恢复：上传顺序、检查点与清理。 设计原则：状态归属与写入协调。 历史系列介绍 v0.1 产品计划、设计决策与测试，以及 v0.2 重构和后续版本，并链接到对应源码快照。 当前命令见 SOW 文档，各版本变化见发布说明。