Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions

[graydon hoare]

Tom Lord <address@hidden> writes:

> Signatures provide an imperfect mechanism for _communicating_
> expression of trust and assertions about trust.  [...] 

I take it by all this you're trying to paraphrase:

http://www.counterpane.com/crypto-gram-0011.html#1

which is a well-known and accepted risk, which many tools carry. we
all know signatures are only a weak approximation of trust intent,
they're just practical, and as good as the technology currently gets.

> I'm guessing that you, graydon, work in a typical office-park type
> setting or else in a typical home somewhere.  Do you really think
> your keys are so secure?

of course not. as I said, all trust devices have failure
modes. monotone's isn't much worse than any other, though.

> People who want to reduce the human experience of "trust" to a game
> that you can plan on the internet are, as they say, Missing The
> Point. 
> [ ... ]
> There's a bit of a difference between digitally mediated development
> and extension of trust and scientific experiments.  

so, if I read correctly your suggested solutions to having a machine
evaluate the trustworthyness of a version in a VC system boil down to
one of:

  - meet the author in person and exchange checksums, using your latent 
    human social-trust evaluation ability
  - run the testsuite on every possible failure you're concerned about

I agree that these would be stronger, but argue that both are
prohibitively expensive to perform on each update operation.

> Why, then, a version-control-specific solution?

because it's a version control tool. lots of tools build their
security parts in, just like they build their own parsers or printers,
network protocol code, etc. good ol' monolithic design.

> Furthermore, the stated goals on the web page about "acceptance
> criteria" don't jive very well with the scenario of in-house QA
> talking to other parts of the company.   It makes no sense.

it makes more sense if you include the part of the sentence I wrote
which says "(or developer community)".

> I don't follow you there.   I mean, I get the literal meaning but I
> don't see the point.

my point was merely to contest your criticism of 'mission creep'.
certs have a simple, well-defined purpose in monotone, and I think
they serve that purpose well.

> We'll see.   There's a fairly comprehensive solution to this in the
> inventory/mkpatch/dopatch mechanisms of arch which it may be helpful
> to consider.

I will look your code and examples over.

> "Seen to be renamed" implies an access on both ends to complete
> history and agreement upon a common reference revision.

all operations which consider renaming are performed against a local
database, so there are no "both ends" to the situation. as I said
before, if you have enough history (in your local database) you will
see the rename. if not, you will see a delete+add pair.

>     > > That you wind up ignoring empty directories is a bug.
> 
>     > I see. it seems people keep caring about empty and moved directories.
>     > I hadn't previously thought of them as important enough to warrant
>     > effort, but I suppose I shall add support for them. your examples are
>     > worth addressing. thanks for the tip.
> 
> Glad to help.

thinking it over, I'm still not completely sold on explicit
representation of directories. if a rename affects anything but the
last component of a path, it's obviously a directory rename. in fact,
considering it, such renames are easy to analyze and propagate during
a merge. I think explicit representation could still be avoided. the
empty directory case I do not really worry about. 

-graydon