Re: Mercurial 0.4b vs git patchbomb benchmark

[Tom Lord <lord@emf.net>]

   From: Horst von Brand <vonbrand@inf.utfsm.cl>

   Now pray tell how Joe signing one, two, three, or none of the things he is
   juggling makes any difference here.

We are talking about these signable things:

	1) Joe's assertions about the ancestry of his 
	   change.

	2) A full tree that Joe believes contains exactly
	   his change, compared to the ancestry, in some
	   well-defined way.

	3) A "patch" -- a statement of the well-defined 
	   change Joe is making.


Signing (1) is mandatory if history-sensitive merges are to be
possible.

If everything works perfectly, then signing (1) and (2) is
mathematically equivalent to signing (1) and (3) and both are
equivalent to signing (1), (2), and (3).

Things don't work perfectly.

A document containing (1) and (2) is, almost by definition, a "human
scale" document.   It reprepresents a real-world unit of human labor.
It summarizes the product of that labor in a human-readable, compact
form.   In most cases, a person could study a (1),(2) document in
great detail, byte for byte, relying on very few software tools.

By contrast, a document containing (1) and (3), for a project as large
as the kernel, can not be described as a "human scale" document: it
represents the product of vast amounts of human labor -- exceeding a 
single human's capacity to fully comprehend.   There are just too many
bits there for a full tree to specifically represent a single human's 
detailed *intensions* except indirectly.

You are countering, essentially, that programmers are afforded plenty
of tools for comparing two trees.  Therefore, as I understand you, any
programmer with working tree-comparison tools can robustly commit a
(1),(3) pair accurately.  Similarly, any programmer can robustly
receive a (1),(3) pair and study it as if it were a (1),(2) pair -- so
where's the problem?

The problem is in lot's of places but perhaps the clearest summary can
be presented as a communications problem.  Supposing that work is done
entirely with (1),(3) pairs:


	Alice and Bob both have a copy of the tree ORIG.

	Alice makes changes and now also has tree MOD_alice.

        Alice examines her changes locally.  Her
	version of the changes, summarized as a patch (aka changeset)
        is: CHANGES_alice.

	Alice signs the pair <ORIG, MOD_alice> (a (1),(3) pair) and
	sends it to Bob.

	Bob faithfully retrieves MOD_alice.

	Bob compares Mod_alice to ORIG, using robust tools 
	he has at hand.  The patch (aka changeset) which 
	summarizes the differences in his view is: CHANGES_bob.


Nothing in this scenario gives Bob a way to prove that CHANGES_bob ==
CHANGES_alice.  Bob can be as certain as we are content with that he
wound up with the same _tree_ that Alice did, but he and Alice will
have to go out of their way if they want to check their communication
in such a way that Bob can be confident Alice has checked that she
said what she meant to say.

More bluntly, given just a (1),(3) pair, Bob is extending his vulnerability
to include a reliance on Alice's patch-computing tools.   If Alice were
known to be signing a (1),(2) pair which she had reviewed in detail,
then Bob's vulnerability stays at just his local patch-handling tools
and his general trust of Alice.

In general, it's the potential specificity of a (1),(2) signature, rather
than a (1),(3), that makes (1),(2) signing the more robust idea (from
the robustness perspective).


-t