Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any.

On 2020-06-08 07:31, Daniel Shahaf wrote:

Manuel Jacob wrote on Sun, 07 Jun 2020 15:31 +0200:

Hi Daniel,

On 2020-06-07 14:14, Daniel Shahaf wrote:
> Manuel Jacob wrote on Sun, 07 Jun 2020 09:44 +0200:
>> "Topics" is an experimental concept in Mercurial that augments the
>> current branching concept (called "named branches").
>>
>> For more information, see the not always up-to-date Mercurial Wiki
>> page
>> https://www.mercurial-scm.org/wiki/TopicPlan.
>
> I assume "experimental" means "future releases of Mercurial are not
> promised to be backwards compatible with the current design".

It is not yet part of Mercurial itself, but developed separately as an
extension under the Mercurial project roof.



Thanks for the info.  In practice, though, it doesn't make that much
difference to vcs_info whether the functionality lives in Mercurial core 
or in an extension developed by the same development team.  I was more
concerned with whether the current on-disk data format is promised to be 
supported by future releases of the functionality [whether those be in
hg core or in extensions].


> Is the .hg/topic file name and data format set in stone yet?
>
> What if zsh 5.9 is released and then the Mercurial developers change
> the design to make .hg/topic a directory, and release _that_?  Then
> everyone who uses zsh 5.9 with hg will be stuck with vcs_info errors
> until their distro upgrades to newer zsh.

The .hg/topic file works very similar to the .hg/branch file (which is
stable since 2007 and which zsh currently depends on). I can't think of 
any reason why someone would consider changing the format.
I'm not going to second-guess your assessment, but I am surprised by it.
The main developer of the topic extension said that there will be clear message if it changed. When I asked him "do you think it is safe for a shell prompt hook to depend on the .hg/topic file name and data format?", the answer was "safe enough". What he considers "safe enough" might not be "safe enough" for zsh. As a zsh user, I find it reassuring that the standards for inclusion are high. 


The file would only be created if a user installs and activates the
extension, and explictly creates a topic (a specific kind of feature
branch), so that makes it even more unlikely that something breaks.


I do see that if topics are not popular, then the probability that
a random hg user would be affected by a forward incompatible assumption
in vcs_info is low.  However, users of hg topics that uses vcs_info
_would_ be affected and would have no easy workaround.

Furthermore, it is zsh, not hg, who would receive the consequent bug
reports and negative word-of-mouth.

Could you comment on what options are there to design forward
compatibility into the patch? It would be good to lay out alternatives, 
even if we don't end up implementing any of them.
One option is that people would have to opt-in to get the topic shown. This way, people could be made aware that they’re using something that could break in the future. However, I don’t know whether zsh provides a framework for having this kind of configuration.
The hook could check harder that the .hg/topic file is in the expected format, e.g. checking that it is a regular file. As long as it’s a regular file, I’d consider it a gross violation of the user expectation if the file contained anything other than simply the topic name.
I could submit the diff of this patch for inclusion in the "contrib" directory of the topic extension repository to remind them that people depend on the file name and data format. 


Cheers,

Daniel


> Cheers,
>
> Daniel
>
>> ---
>>  Functions/VCS_Info/Backends/VCS_INFO_get_data_hg | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
>> b/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
>> index cd5ef321d..e898f7298 100644
>> --- a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
>> +++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
>> @@ -5,7 +5,7 @@
>>
>>  setopt localoptions extendedglob NO_shwordsplit
>>
>> -local hgbase bmfile branchfile rebasefile dirstatefile mqseriesfile \
>> +local hgbase bmfile branchfile topicfile rebasefile dirstatefile mqseriesfile \
>>      curbmfile curbm \
>>      mqstatusfile mqguardsfile patchdir mergedir \
>>      r_csetid r_lrev r_branch i_bmhash i_bmname \
>> @@ -27,6 +27,7 @@ mergedir="${hgbase}/.hg/merge/"
>>  bmfile="${hgbase}/.hg/bookmarks"
>>  curbmfile="${hgbase}/.hg/bookmarks.current"
>>  branchfile="${hgbase}/.hg/branch"
>> +topicfile="${hgbase}/.hg/topic"
>>  rebasefile="${hgbase}/.hg/rebasestate"
>>  dirstatefile="${hgbase}/.hg/dirstate"
>>  mqstatusfile="${patchdir}/status" # currently applied patches
>> @@ -69,6 +70,13 @@ fi
>>  # If we still don't know the branch it's safe to assume default
>>  [[ -n ${r_branch} ]] || r_branch="default"
>>
>> +# Show topic if there is any (the UI for this experimental concept is not yet
>> +# final, but for a long time the convention has been to join the branch name
>> +# and the topic name by a colon)
>> +if [[ -r ${topicfile} ]] ; then
>> +    r_branch=${r_branch}:$(< ${topicfile})
>> +fi
>> +
>>  # The working dir has uncommitted-changes if the revision ends with a
>> +
>>  if [[ $r_lrev[-1] == + ]] ; then
>>      hgchanges=1
Messages sorted by: Reverse Date, Date, Thread, Author