Adding phase support to TortoiseHG

[Angel Ezquerra]

On Sun, Jan 22, 2012 at 8:59 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
> On 22 janv. 2012, at 20:42, Angel Ezquerra wrote:
>
>> On Sun, Jan 22, 2012 at 10:59 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>>
>>> On 22 janv. 2012, at 02:03, Angel Ezquerra wrote:
>>>
>>>> I have a few more questions:
>>>> - do mq patches have phase information? If not, should they be
>>>> considered draft or secret?
>>>
>>> applied mq patch have phase information: they are secret in simple case.
>>> unapplied mq patches do not hold patches information but will be applied
>>> as secret.
>>>
>>> * mq are qnew'ed as secret
>>> * mq are qpush'ed as secret
>>> * qrefresh result are secret
>>>
>>> But, you can change the phase of an mq patche to draft (or event public!)
>>>
>>> eg: revision are qimported in the phase they are.
>>>
>>>> - is the list of phase names publicly available in some accessible
>>>> list? I must show the list of phases in order to let the user change
>>>> the phase from the guy, but I'd rather not hard code the different
>>>> phase names
>>>
>>> mercurial.phases.phasenames
>>>
>>>> - is there an easy way to tell if we are trying to move the phase
>>>> backward? I'd like to warn the user and ask him if he wants to force
>>>> the phase change in that case. Since there are only 3 phases I could
>>>> simply take all possible cases into account, but I'd rather use a more
>>>> general solution, in case new phases are added in the future.
>>>
>>> mercurial.phases.allphases hold the numerical value of phases. You are
>>> moving it backward when::
>>>
>>>        dest-phase > orig-phase
>>>
>>> Moreover, you have to use different function to move phase in both direction.
>>> so you can not more phase backward by mistake is you use advanceboundary.
>>>
>>> See the phase command for details
>>
>> TortoiseHg usually calls mercurial commands directly so my plan is to
>> call the commands.phase function, rather than the advanceboundary and
>> retractboundary functions.
>>
>> I am a bit surprised that commands.phase does not return a value. I
>> expected it to return False if the phase was changed and True if it
>> didn't (e.g. if --force is necessary).
>
> It does…
>
> return 0 if their was some phases movement.
> return 1 if nothing moved.
>
> But does not informs that --force could help in moving something.

I see it now. The revision I was reading was a bit old and in it the
phase command did not return any values yet.

Unfortunately the phase command returns 1 when no phases changed. I
guess that can happen if you try to change the phase of a revision to
its current phase. Thus I cannot just check the return value of the
phase command to determine if I should ask the user if we wants to
force the phase change. I don't know if this is done in other
mercurial commands but it would have been nice if there were more than
one possible non-zero return codes, each indicating a different type
of "error".

I guess I'll just have to read the current and target phases and show
the warning if the requested phase is lower than the current one, as
you suggested.

Angel