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

[Daniel Shahaf <d.s@daniel.shahaf.name>]

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

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