[PATCH] obsolete: add operation metadata to rebase/amend/histedit obsmarkers

[Pierre-Yves David]

On 05/19/2017 07:17 PM, Jun Wu wrote:
> Excerpts from Gregory Szorc's message of 2017-05-19 09:51:46 -0700:
>>> I agree with Pierre-Yves that the bit-based solution seems better
>>> long-term. I'm not particularly worried about wasting bits. I was also
>>> happy for Durham's patch as a short-term solution. But since
>>> Pierre-Yves et al are already working on the bit-based solution, I'd
>>> prefer to give them at least a month to make progress on that.
>>
>> Perfect is the enemy of done.
>>
>> If we're really uncomfortable with the strings, we can put that behind an
>> experimental config or requirement so we don't pollute real repos. Then we
>> can figure out something before 4.3. At least this way something lands and
>> some progress is made (even if the exact implementation doesn't pan out).
>
> Talking about perfection, I also don't think the 3 bits: parent-change,
> content-change and metadata-change is a good abstraction.
>
> Because they are redundant data. They can be calculated afterwards, in a
> cache.

No they can not. The obsolescence graph can contains reference to node 
we do not have locally then we cannot compute the "effect" of operation 
between these nodes.

Storing the effect are creation time is important. For example, I can 
see that both Alice and Bob rewrote a changeset between two locally 
known version. If I need to dig deeper, I can use the effect-flags to 
discover that Alice changed the code but Bob is the one who did the 
description proof reading and the rebase,

Commands like the new 'obslog' needs that information in the marker to 
provide with usable output.

Please make sure to take the distributed case in account when thinking 
about evolution design.

> Having them in obsstore means we could have inconsistency - changelog
> disagrees with obsstore about the flags (data written by some bad
> extensions) - how would you deal with that?

The effect-flags are used for informative output only, so if it bad, 
there will be slight confusion, but nothing will break.

Client are not supposed to create bad one, but we cannot guarantee that. 
If we want to be paranoid, we could have a server setting to double 
check received marker chains are "okay" (that will probably be a bit 
expensive).

> "operation" metadata is not redundant - you cannot get them from elsewhere
> so they should be recorded.

Locally, we already have the command information in the journal. And 
once we cross the distributed barrier, the content of "operation perform 
very poorly.

-- 
Pierre-Yves David