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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri May 19 18:20:08 EDT 2017


On 05/19/2017 10:49 PM, Jun Wu wrote:
> Excerpts from Pierre-Yves David's message of 2017-05-19 22:08:31 +0200:
>>> 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,
>
> If it's for divergence resolution - anyone who has the original changeset
> could figure out what to do without the obsstore flags.

No, this is to offer informative (and zoomable) capability to look at 
the obsolescence history. It is to be used by human user, this class of 
feature is an actual requestion from actual team testers.

Most of the rest of your reply seems to be around divergence resolution 
so I'll drop it for now.

>>> "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.
>
> journal is an extension and is experimental and I do have plans to make big
> changes to it. obsstore is in core already. I don't think we should depend
> on journal for now.

Evolution is an experimental feature with most of it UI in an extension, 
so this is not too different. Journal is an extension dedicated to 
keeping track of locally executed commands, this seems to fit your 
"operation" use case well. This is why I'm pointing at it.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list