[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