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

Augie Fackler raf at durin42.com
Fri May 19 13:22:26 EDT 2017


> On May 19, 2017, at 10:17, Jun Wu <quark at fb.com> 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. 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?
> 
> "operation" metadata is not redundant - you cannot get them from elsewhere
> so they should be recorded.

I'm satisfied at this point in the thread that it's worth experimenting with storing these strings, and if we're worried about the size increase we can disable the storing of the metadata before 4.3 goes final.

Patch is queued. Thanks everyone.


More information about the Mercurial-devel mailing list