Thread (30 messages) flat view 30 messages, 13 authors, 2016-06-15

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

From: Theodore Tso <tytso@mit.edu>
Date: 2016-06-15 22:43:04

On Sun, Apr 15, 2007 at 07:17:29PM -0700, Robin H. Johnson wrote:
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help