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
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
