[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