Re: Weird shallow-tree conversion state, and branches of shallow trees

From: Theodore Tso <tytso@mit.edu>
Date: Apr 16, 2007, 03:01 UTC
Message-ID: <20070416030103.GB27533@thunk.org>
In-Reply-To: <20070416021729.GH2689@curie-int.orbis-terrarum.net>

On Sun, Apr 15, 2007 at 07:17:29PM -0700, Robin H. Johnson wrote:

Show 18 quoted lines

> Nobody has addressed the single problem that I have with adding it when
> it's leaving the environment, and that's still of paramount concern to
> me. Simply put, there is a conflict between being able to add revision
> information of stuff leaving the environment, and those additions
> breaking previous checksums (which may be digitally signed, and thus
> breaking the signatures).
> 
> I'll reduce it further from my previous example.
> 
> 1. Developer commits some change to file A.
> 2. The checksum file is updated because A changed (the checksum file
>    explicitly does not contain keywords).
> 3. Developer signs the checksum file, and commits it.
> 
> If during the export process (which is undertaken elsewhere, by a
> different person or script), file A now has an expansion applied to it,
> you break the checksum file, which you CANNOT redo, because you lose the
> developer's digital signature on the checksum file!

Simple, the release engineer runs a script which exports the tree, expanding any keywords and updating the checksum file as necessary, and then the release engineer signs the checksum file! As has already been stated, if this doesn't work, you probably don't have a well defined and formal release process.

Just because a developer has signed a checksum doesn't mean that the tree is suitable for release; that's the job of the release engineer to confirm, probably after running a set of regression test suites. And in fact, with git, it's pointless for the developer to sign a checksum file and then commit it, since git is already maintaining checksums as an integral part of how revisions are named.

					- Ted