Adding phase support to TortoiseHG

[Angel Ezquerra]

On Sun, Jan 22, 2012 at 10:49 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
> 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

That is weird. If they behave as draft, why show them as public??

I really don't know much about how a regular repo will be upgraded to
add phase info to it. Is there a web page explaining the process? In
your opinion, should we add support for that to TortoiseHg as well?


>> - 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.

I really don't know what you are talking about here :-P This is the
first time that I hear about "callbacks" in the context of mercurial.
Can you please elaborate a bit further what you mean?

Isn't there some "hasphase" repo method or similar that I can use to
tell if a repo has phase information?

Cheers,

Angel