From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Manuel Jacob <me@manueljacob.de>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any.
Date: Tue, 9 Jun 2020 22:34:16 +0000 [thread overview]
Message-ID: <20200609223416.59a43074@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <538786d4a3afe4b9432a1469ebafcad8@manueljacob.de>
Manuel Jacob wrote on Tue, 09 Jun 2020 03:15 +0200:
> 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.
Thanks for going to the horse's mouth. Yes, "safe enough" is a bit
vague.
> As a zsh user, I find it reassuring that the standards for inclusion are high.
Thanks for your understanding and for making it explicit ☺
> >> 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.
>
Configurability could be provided via the 'zstyle' builtin. Briefly,
zstyles map strings ("contexts") to key-to-list-of-words maps by
specifying pattern that contexts are matched against. (See the manual
for details.) A user might do in their zshrc
.
zstyle ':vcs_info:hg:*' experimental-features topic
.
and then the vcs_info backend would run «zstyle -a» and get an array
«reply=( topic )». Without that zshrc setting, the array would be
empty.
There should be plenty of examples of this in vcs_info, and more in the
completion system.
> 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.
>
Makes sense. This way, if there _is_ an upstream backwards-incompatible
change [which is fine, of course, in an experimental feature], the
fallout would be minimal.
Or maybe vcs_info could read just the first line of the file. This
way, if future hg adds more info in subsequent lines, we'll be forward
compatible with that.
> 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.
Making upstream aware that it has downstreams that depend on the data
format would definitely be a Good Thing. A contrib patch wouldn't have
been my first choice, though: I'd rather recommend creating a unit test
that creates and reads a topic in the same way vcs_info will, with
a comment explaining that (and a comment in vcs_info that points to the
test).
Or perhaps the vcs_info hg backend should be maintained as part of hg?
That would require vcs_info to provide a public API for third-party
backends.
Cheers!
Daniel
next prev parent reply other threads:[~2020-06-09 22:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-07 7:44 Manuel Jacob
2020-06-07 12:14 ` Daniel Shahaf
2020-06-07 13:31 ` Manuel Jacob
2020-06-08 5:31 ` Daniel Shahaf
2020-06-09 1:15 ` Manuel Jacob
2020-06-09 22:34 ` Daniel Shahaf [this message]
2020-06-17 8:27 ` Daniel Shahaf
2020-06-19 2:06 ` Manuel Jacob
2020-06-19 10:07 ` Daniel Shahaf
2020-06-19 10:46 ` vcs_info patch-format/applied-string awareness? (was: Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any.) Daniel Shahaf
2020-06-19 22:48 ` vcs_info patch-format/applied-string awareness? Manuel Jacob
2020-06-20 9:54 ` Daniel Shahaf
2020-06-20 22:06 ` Manuel Jacob
2020-06-19 23:29 ` [PATCH] Add code to Mercurial VCS backend to show topic if there is any Manuel Jacob
2020-06-20 10:43 ` Daniel Shahaf
2020-06-07 13:49 ` Manuel Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200609223416.59a43074@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=me@manueljacob.de \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).