[PATCH 4 of 4 V2] obsolete: allow cycles
raf at durin42.com
Tue Mar 21 18:03:33 EDT 2017
On Mon, Mar 13, 2017 at 10:11:34AM -0700, Jun Wu wrote:
> Excerpts from Durham Goode's message of 2017-03-13 09:23:49 -0700:
> > On 3/13/17 2:48 AM, Jun Wu wrote:
> > > # HG changeset patch
> > > # User Jun Wu <quark at fb.com>
> > > # Date 1489395002 25200
> > > # Mon Mar 13 01:50:02 2017 -0700
> > > # Node ID 6ae6d1069ba1d4089afaeb0bb8ef2411983a1292
> > > # Parent 0280ee091bd0ae33aa0a67b0c8a55ccffd2e0718
> > > # Available At https://bitbucket.org/quark-zju/hg-draft
> > > # hg pull https://bitbucket.org/quark-zju/hg-draft -r 6ae6d1069ba1
> > > obsolete: allow cycles
> > >
> > > Now we can handle cycles nicely, allow them to be created. Some practical
> > > examples:
> > >
> > > - To revive X, just create a marker X -> X, with a newer date.
> > > - To prune X again, just create a marker X -> (), with a newer date.
> > > - The above two could be repeated.
> > >
> > > - To unamend A -> B, just create a marker B -> A, with a newer date.
> > >
> > > It's now possible for "touch" and "unamend" to reuse hashes (therefore more
> > > user-friendly). And it's no longer necessary to write "*_source" in commit
> > > metadata to workarounds obs cycles. The hacky inhibit extension also becomes
> > > unnecessary.
> > >
> > > Finally. I have been wanting all these for a long time.
> > Seems pretty elegant,
> It is. I didn't believe I solved it using just 40+ lines with reasonable
> performance :p
> > though I haven't fully understood it yet. Maybe
> > you guys talked about this in person,
> That's what happened. And we decided to use "date" as the version number.
> > but what effect (if any) does this > have on exchange?
> As long as exchange sends dates, markers are globally ordered, and they
> behave no different then the local case.
> Say Alice has A -> B created on date1, Bob has B -> A with date2. If date2 >
> date1, Bob wins. The time of pulling or the pull direction does not matter.
> Only the global version (date) matters. If date2 == date1, two markers
> "cancel out" and both A and B become visible. Previously no matter what the
> dates are, A and B are both permanently invisible.
I do worry a little about someone with a bogus clock years in the
future pumping out malicious nodes that can't be overridden, but I
suppose in that case your "way out" is that you perturb the hash of
the revision(s) you want to keep. Seem good enough?
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel