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

[Manuel Jacob <me@manueljacob.de>]

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