From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12302 invoked from network); 8 Jun 2020 05:32:44 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2020 05:32:44 -0000 Received: (qmail 1397 invoked by alias); 8 Jun 2020 05:32:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 46024 Received: (qmail 24834 invoked by uid 1010); 8 Jun 2020 05:32:29 -0000 X-Qmail-Scanner-Diagnostics: from wout4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(64.147.123.20):SA:0(-2.6/5.0):. Processed in 5.600151 secs); 08 Jun 2020 05:32:29 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehtddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtje dttdertddvnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpefggeeiledtveffge duieekheelffekheetheelheekkeeujeejtdeftdehueelveenucffohhmrghinhepmhgv rhgtuhhrihgrlhdqshgtmhdrohhrghenucfkphepjeelrddujeeirdefledrieelnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Mon, 8 Jun 2020 05:31:40 +0000 From: Daniel Shahaf To: Manuel Jacob Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any. Message-ID: <20200608053140.33e79354@tarpaulin.shahaf.local2> In-Reply-To: References: <20200607074445.7723-1-me@manueljacob.de> <20200607121443.7c58ee16@tarpaulin.shahaf.local2> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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