[PATCH 4 of 4 V2] obsolete: allow cycles

Augie Fackler raf at durin42.com
Sun Mar 26 16:04:32 EDT 2017


> On Mar 26, 2017, at 2:25 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> 
> It seems like we're shooting ourselves in the foot by consolidating all markers into a single local store. Have we ever considered having a separate store per remote or at least preserving the illusion of a separate store (e.g. by recording metadata such as "markers N to M pulled from X")? This would preserve properties of strict ordering within each peer. There are still problems of figuring out the relative ordering between markers produced on different peers (with different clocks). But without online coordination at the time of marker generation, this is *impossible* to achieve. The best you can do is preserve strict ordering within each source and exchange/record generation numbers (e.g. marker number/offset) to attempt to resolve relative ordering and to drive "merging."

I’ve considered a similar line of thinking for prunes (basically having “local” markers and “exchanged” markers, and by default not propagating prunes). Maybe it’s worth revisiting.


More information about the Mercurial-devel mailing list