Adding phase support to TortoiseHG

[Pierre-Yves David]

On 22 janv. 2012, at 01:34, Angel Ezquerra Moreu wrote:

> Hi,
> 
> I'm working on adding phases support to TortoiseHg. I have a few
> questions that hopefully someone can help me with:

You should have a look at: the changeset that introduce phase support in hgview

http://hg.logilab.org/hgview/rev/6f0ca886050d

Note that at the time this was introduce, mercurial.phases.allphases and mercurial.phases.phasenames did not exists.

> - Looking at the code for the phases command, it seems that the
> easiest way to get the phase for each revision is to use the
> phasestr() method of the context object. Is that correct? I am worried
> that it may be expensive to call that method for each and every
> revision. Is there any other way?

You could look into repo._phaserev directly. But, note that there is currently no guarantee this array is up to date with the repo length.

You should bench the cost of using .phase() before considering using something else.

> 
> - What should be the phase that should be shown when TortoiseHg is
> shown in combination with an older mercurial version? Would that be
> "draft"?

Good question,

* Old repo behave as "all draft", but without any security. On new repo you can think that draft changeset can be safely[1] rewritten.

* One upgraded, they will public.

In hgview, I decided to show them public


> - What is the best way to tell if a repo has any phase data and
> whether it is a publishing or a non publishing repo? Old repos are
> considered non publishing, right?

* Old repo are publishing.

You can register a callback used when no phase data are available on a repo. This is originally intended to allow extension like mq to tune the default phase value, but you could use it to know if logic was triggered.

-- 
Pierre-Yves David

[1] mostly safely