Skip to content

Tags: repository

  • SOW Design Evolution: From Route Graphs to the Repository Core

    By Vonng In Design 893 words 5 min

    VonngDesignarchitecturerepositorymigrationdecision

    SOW Design Evolution: From Route Graphs to the Repository Core

    This record dates to the 2026-08-10 consolidation of SOW around its Repository core. It distills the useful decisions from the earlier planning, ADR, review, migration, and verification trees without turning every intermediate artifact into …

    This record dates to the 2026-08-10 consolidation of SOW around its Repository core. It distills the useful decisions from the earlier planning, ADR, review, migration, and verification trees without turning every intermediate artifact into …

  • Design Principles

    By Vonng In Design 595 words 3 min

    VonngDesignplainmanagedrepository

    Design Principles

    SOW is not primarily a metadata generator. It is an ownership and state-transition system whose output happens to be APT and RPM repositories. The following principles keep that system small enough to reason about. One owner for every durable fact …

    SOW is not primarily a metadata generator. It is an ownership and state-transition system whose output happens to be APT and RPM repositories. The following principles keep that system small enough to reason about. One owner for every durable fact …

  • System Model

    By Vonng In Design 569 words 3 min

    VonngDesignrepositorydistpoolgeneration

    System Model

    The model is deliberately layered. Configuration expresses intent, the database records owned state, and the public tree is a deterministic projection. None of those layers may quietly become a substitute for another. Object hierarchy Workspace ├── …

    The model is deliberately layered. Configuration expresses intent, the database records owned state, and the public tree is a deterministic projection. None of those layers may quietly become a substitute for another. Object hierarchy Workspace ├── …

  • Why SOW Uses One Payload Tree per Repository

    By Vonng In Design 738 words 4 min

    VonngDesignrepositorypoolrpmaptcompatibilitydecision

    Why SOW Uses One Payload Tree per Repository

    This decision was drafted on 2026-08-05 during the pre-v0.2 release design consolidation and shipped in SOW v0.2.0 on 2026-08-08. It remains the layout contract in v0.3 and v0.4. It records an architecture choice, not a blanket compatibility claim: …

    This decision was drafted on 2026-08-05 during the pre-v0.2 release design consolidation and shipped in SOW v0.2.0 on 2026-08-08. It remains the layout contract in v0.3 and v0.4. It records an architecture choice, not a blanket compatibility claim: …

  • sow repo

    In Commands

    Commandclirepositorymanaged

    A Repository owns one pool/, one dists/, one SQLite database and one private state directory. It is the boundary of locking, transaction recovery, Generation numbering and Changesets — nothing is deduplicated across Repositories and no …

    A Repository owns one pool/, one dists/, one SQLite database and one private state directory. It is the boundary of locking, transaction recovery, Generation numbering and Changesets — nothing is deduplicated across Repositories and no …

  • Repository Layout

    In Reference

    Referencerepositorypooldist

    SOW has one fixed Managed layout: package payloads live once under pool/, while dists/ contains metadata-only client views. The complete repository directory is the unit to serve, copy, or publish. Plain mode sow create writes indexes next to …

    SOW has one fixed Managed layout: package payloads live once under pool/, while dists/ contains metadata-only client views. The complete repository directory is the unit to serve, copy, or publish. Plain mode sow create writes indexes next to …

  • Core Concepts

    In Get Started

    Startplainmanagedrepositorydist

    Plain or Managed The two execution paths are separate. Plain Managed Entry point sow create DIR init, repo, dist, add, rm, build State package directory sow.yml plus private SQLite/journals Public layout flat RPM/DEB indexes Repository pool/ + dists/ …

    Plain or Managed The two execution paths are separate. Plain Managed Entry point sow create DIR init, repo, dist, add, rm, build State package directory sow.yml plus private SQLite/journals Public layout flat RPM/DEB indexes Repository pool/ + dists/ …

  • Managed Workspaces

    In Features

    Featuremanagedrepositorydistgeneration

    Managed mode is what you use when the same repository will be updated for months: packages arrive in batches, policy decides what stays, and you need to prove afterwards what changed and when. This page explains the three-tier model, the layout it …

    Managed mode is what you use when the same repository will be updated for months: packages arrive in batches, policy decides what stays, and you need to prove afterwards what changed and when. This page explains the three-tier model, the layout it …

  • Your First Workspace

    In Get Started

    Startmanagedrepositorydistgeneration

    Managed mode keeps configuration, membership, generations, and audit state. This example starts from an empty directory. Initialize the workspace sow init /srv/sow cd /srv/sow init creates: /srv/sow/ ├── sow.yml # configuration; schema: sow/v3 └── …

    Managed mode keeps configuration, membership, generations, and audit state. This example starts from an empty directory. Initialize the workspace sow init /srv/sow cd /srv/sow init creates: /srv/sow/ ├── sow.yml # configuration; schema: sow/v3 └── …