[PATCH 1 of 2] phases: add a phase and phasestr method to file context
mpm at selenic.com
Wed Oct 17 14:10:27 CDT 2012
On Wed, 2012-10-17 at 13:08 -0500, Sean Farley wrote:
> On Wed, Oct 17, 2012 at 12:49 PM, Pierre-Yves David
> <pierre-yves.david at logilab.fr> wrote:
> > On Wed, Oct 17, 2012 at 10:38:40AM -0500, Sean Farley wrote:
> >> On Wed, Oct 17, 2012 at 10:33 AM, Pierre-Yves David
> >> <pierre-yves.david at logilab.fr> wrote:
> >> > On Wed, Oct 17, 2012 at 10:28:20AM -0500, Sean Farley wrote:
> >> >> # HG changeset patch
> >> >> # User Sean Farley <sean.michael.farley at gmail.com>
> >> >> # Date 1350425390 18000
> >> >> # Node ID 072adc076e641990cf0000ece34e9545ebaaa0b3
> >> >> # Parent 72c234081ae1350220132c69750f5a093902a1e7
> >> >> phases: add a phase and phasestr method to file context
> >> >
> >> > Hey? we already have them!
> >> But not for filecxt :-( ... unless I am missing something about
> >> wanting to call 'ctx.phasestr()' without having to test whether it is
> >> a changectx or filectx?
> > Not that filectx is very deceptive. It usually point to the **first revision**
> > that introduce a content. This revision may be a different revision that the
> > one you care about. With a differrent phase (and different visibility)
> > :-(
> Hmm, then I'm confused how functions like
> def date(self):
> return self._changectx.date()
Here, _changectx is one of:
a) the changectx you explicitly used to get here
b) the changectx of the node you used to get here
c) the changectx of the filectx's linkrev, if you got here by following
the file graph
(a) and (b) are trouble-free. So things like
repo[rev].p1()["somefile"].date() will always do the right thing.
(c) is a changeset that introduced this file revision, but it's not
guaranteed to be the only one. So repo[rev][file].p1().date() may not be
what you expect. This is a side effect of the fact that we only store
one linkrev per file revision.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel