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

Martin von Zweigbergk martinvonz at google.com
Fri May 19 13:23:41 EDT 2017


On Fri, May 19, 2017 at 10:17 AM, 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.

That's a great point! I really hate linkrevs for exactly that reason
(I understand that they were useful, but they also cause so many
problems). Caches have their own problems, of course :-)


More information about the Mercurial-devel mailing list