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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri May 19 16:12:33 EDT 2017



On 05/19/2017 06:54 PM, Jun Wu wrote:
> Excerpts from Martin von Zweigbergk's message of 2017-05-19 09:39:41 -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.
>
> I think the bits do not contain enough information. Consider "absorb", it's
> "content-change" so would you show "amend as" or "absorb as"? There are
> other content-rewriting commands that are not "amend".

The general philosophy here is to express the fact the content changes.
We do not really care how (user already have journal and blackbox to 
understand the how).

Effect-flags store different data (more detailed on some aspect, less on 
other), in a way that work well on distributed system (evolution goal) 
with negligible size overhead. Sure there are trade off on what we store 
but it is unclear that they matters.

I would rather focus on experimenting with the one approach that work 
well in the distributed case (and already available). We might end up 
not needing anything extra on top of it.

> The obsstore will have a format change to support hash-preserving (I'll try
> to get some plans public in the near future)

I'm looking forward to have the plan details published. Our discussion 
were promising.

> and I plan to de-duplicate all
> strings stored there so space usage is less a concern.

Okay that is something different. I've not heard of details yet so I 
would be happy to learn more about it. Until then it seems a bit 
optimistic to ignore size impact.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list