[Monotone-devel] Re: current multiple heads (was Re: write access to my public server)

[graydon hoare]

graydon hoare wrote:

>  - rework the concept of disapproval to "do something else". for
>    example, 

... having thought on the matter for some while longer, I think I have a 
simpler synthetic solution here which actually solves a problem many 
people have complained about: that "equal tree content" always implies 
"equal SHA1" in monotone. there are some cases -- reverting a patch for 
example, but also splitting patches -- in which you don't want this to 
be true. so I propose an automated method for permitting people to break 
SHA1 identity, when they want/need to.

the controlled method is very simple: a file called .mt-nonce goes in 
the working copy which contains some respectably large number (say 4096) 
of random bits. a new command -- "monotone bump" -- generates a new set 
of bits and stores them in this file. the "merge" operator gains one 
special case regarding this file: it does a normal 3-way merge, but when 
it finds a conflict it simply XORs the files together. so .mt-nonce can 
*always* be merged deterministically (XOR is handy here because it is 
associative and commutative, so merging ((A,B),C) and ((C,B)A) produces 
the same output; it should also preserve the nonce collision 
probability, though smarter crypto heads in the audience may argue me 
out of this belief if misguided)

this makes the "disapprove" command relatively simple: rather than 
trying to "undo" things in the ancestry graph, disapproving A->B means 
making an edge B->A' where A' == A, only with a bumped .mt-nonce file. 
there is historical *record* of your disapproval, and in order to return 
to a single head, any subsequent merging activity has to integrate your 
disapproval (which is essentially "reverting").

I won't be implementing this in time for 0.12, but it strikes me as 
quite feasible within the 0.13 timeframe. does anyone object? it's a 
kludge, but a simple and obvious one.

-graydon