trinque

V, of course, is the republican version control system. The latest client software can be found here. The new client lacks a manifest, and the manifest itself lacks a formal definition, so let's remedy that in short order.

The manifest is used to denote an explicit patch order. Whereas the antecedent hashes of each hunk declare explicit dependency on the patched file's beginning state, the manifest allows the operator to express that, while his patch may not modify the files of a previous patch, the operator's patch nevertheless depends on that antecedent patch being pressed before his.

Suppose a project had a logging facility, and this item was made by psychotic bastards to whom "windows guy" is an archetype. Some poor republican soul comes along to cut and cauterize the macro-overridden printf, only to find that his surgical patch would be lost if no other came to edit - which should be understood "to correct" - his work. Incentives were misaligned at this exact point, is the shortest statement of the problem.

So then, what's a manifest? In the abstract we could get away with very little. Adding and removing the null character from the manifest file in every other patch would work. Obviously this is not a proposal, but it demonstrates that anything more detailed is going to be a matter of operator ergonomics and philosophy-of-v, and not of necessities forced by the data structure.

Thus, I propose the following structure for the manifest, as one line per patch with a single newline between, and single newline terminating, single space between the fields:

$blockCount $patchTitle $patchAuthor $comment

$blockCount - The block height of the Bitcoin blockchain at the time the patch was published. Political time hauls in more definitions and external dependencies than are needed for a global counter. This field should not be interpreted as establishing patch order. It is solely for display to the operator.

$patchTitle - The exact string used to name the patch, sans ".vpatch". This makes things easy on patch viewers, and could be used by a V implementation to throw an error when the patch order expressed by the manifest is *not* the one calculated by V. When a Republican GNS exists, an operator should be able to find and retrieve every patch so named in the manifest.

$patchAuthor - The now deedbot, later GNS name for the patch's author, which resolves to his key.

$comment - Anything not otherwise specified, at the very least a sensible description of the author's patch.

The above describes an idea already put forth by MP here. To declare a "release", an author's GNS pointer for a project would point to his selected manifest. A user would, by retrieving the manifest, have all the information they needed to retrieve the patches and seals required by the project.