Adding phase support to TortoiseHG

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sun Jan 22 13:55:30 CST 2012


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

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

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list