Adding phase support to TortoiseHG

[Angel Ezquerra]

On Sun, Jan 22, 2012 at 8:55 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
> On 22 janv. 2012, at 20:33, Angel Ezquerra wrote:
>
>> 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??
>
> Because if you are using an old mercurial you don't have have any of
> the phase security, so you better not pretend you have.
>
>> 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?
>
> Version of mercurial with phases (2.1+) *always* use phases. If there
> is no phase data stored in the repo it assumes all the content is in
> the public phase.
>
> The phase data are written on every move of the phase boundary. For
> example a new commit made as draft (the default) will change
> the boundary and trigger a writing of data.
>
> You don't need manual operation to enable phases.
>
>
>>>> - 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?
>
> See hgext.mq.mqdefaultphases

I said "a bit", but I hoped you'd not take it so literally ;-)

>> Isn't there some "hasphase" repo method or similar that I can use to
>> tell if a repo has phase information?
>
> Again, every repository has phases. Older mercurial version can't handle them through.

OK, thanks. That makes things simpler.

Angel