Re: [PATCH] keyword: handle filectx _customcmp
* Pierre-Yves David on Friday, October 28, 2016 at 10:35:01 +0200 > On 10/20/2016 11:58 PM, Christian Ebert wrote: >> * Pierre-Yves David on Tuesday, October 18, 2016 at 00:27:21 +0200 >>> On 10/17/2016 05:52 PM, Christian Ebert wrote: # HG changeset patch # User Christian Ebert # Date 1476718966 -7200 # Mon Oct 17 17:42:46 2016 +0200 # Node ID ebef6b5593fa812e907fb4dae920a0c8b2ee00a0 # Parent b85fa6bf298be07804a74d8fdec0d19fdbc6d740 keyword: handle filectx _customcmp >>> >>> I'm not sure why this is an improvement. Can you elaborate on what >>> this changes do and why this is the way to go ? >> >> It was suggested by Yuya: >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089461.html > > Ha okay, I suggest mentioning that in the description next time. Will do. >>> Adding a test case to show what it fixes would be helpful. >>> Related to issue5364. >> >> I have no scenario where this has come up. The scenario of >> issue5364 was caused by an outdated version of the extension. I >> presume it could be seen as a precaution as kwfilectx_cmp >> basically mimics filectx.cmp. >> >> I already admitted cluelessnees regarding the _customcmp idea, so >> for lack of time to dig deeper I relied on Yuya's judgement. > > Relying on yuya judgement is usually a good call ^^ > > However, the 4.0 freeze is in place and that does not seems suitable > for stable, can you resend this when 4.0 is release on November 4.0 ? Sure. -- theatre - books - texts - movies Black Trash Productions at home: https://blacktrash.org Black Trash Productions on Facebook: https://www.facebook.com/blacktrashproductions ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Topics [was: news from the topic experiment]
On 11/01/2016 05:56 AM, Sean Farley wrote: Pierre-Yves David writes: On 10/15/2016 04:18 PM, Pierre-Yves David wrote: On 10/15/2016 08:47 AM, Yuya Nishihara wrote: On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote: Pierre-Yves David writes: So, the other branch of that thread made me realised that we cannot do this "BRANCH:TOPIC" storage in the current "branch" field. An important part of topic is to have them fade away when the changesets become public. This fading away will be implemented client side (logic to stop reading the value). If we expose this data to old client who does not have this logic this means that topic would live as "BRANCH:TOPIC" forever on old client, breaking them in various way. I don't see that. Currently, we have: - old client cannot see topic at all (making it unusable) - new client can see topics If we move to branchname + flag, we have: - old client can see and update using 'hg update NAME' (extremely valuable) - old client can merge a topic to default (extremely helpful and surprising) - new client will hide those branches Your argument is that old clients will see those branches. That's a much better side-effect than not being able to update at all to a topic branch. I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding "BRANCH" is bad because you can't filter log by "branch(BRANCH)" in old client. Exposing topic directly into the branch field means that all the behavior related to named branch will be broken for old clients once someone start using topic in the repository. For example, if a team is using the "foo" branch for development, tracking the head of "foo" is important. Mercurial keeps a set of behavior user rely on, eg: hg up "foo" works, and with this branch active, "hg up" or "hg merge" pick the right head. Now, let's assume the topic information is part of the "branch" field, someone in the team start using topic and do some work on the "bar" topic, their changeset will contains topic informations. For that user, the topic information will just fade away when pushed to the public server. The server will not expose that topic information (because the changeset is public and the server is new), Other team member pulling with a new client will see the "foo" branch move forward as expected without mention of the "bar" topic. However (if the topic information is part of the "branch" field), old clients pulling from that server will get a different result. Instead of having "foo" move forward, they will get a new branch "foo:bar". The branch "foo" will be stuck behind until someone hopefully do work without topic. Breaking the behavior described earlier. In addition this new branch might break various other automation that would now refuse to push a new branch. This highlight how important the control of topic life cycle is. Topics must be able to disappear for public changeset. This is the feature that allow the rest of the Mercurial work flows to keep working for immutable changeset. And this requires the meaning of the "branch" field to stay backward compatible. As a side note, I would like to emphasize that having advanced users about to try out topic without poisoning the common well will be important for adoption. I think your logic is very contrived here. I'm using a full example to show how reusing the same field leads to issue. No, branch names don't have to disappear. That's no "a requirement" as you say. If we could use plain named branch, plain named branch would have an absolute success and every single users would be using them as their core workflow. We are 10 years after their introduction this is not the case. I don't see why they would become the solution we seek for feature branching. The same way, one of the major issue with bookmark is there life cycle and how hard it is to get ride of them. This highlight how important having feature branch name able to fade away is important. What you are suggesting is very over-engineered [1]. Though, it is getting late here and I can respond more tomorrow. I'm not sure what you are referencing with by "what I suggest" here. can you be a bit more specific? I'm confident we can find interesting solution for the various inconvenient the old client will see. For example, (random though), we could not serve topic changesets to old client by default, while still honoring explicit requests in the form "branch:topic". Mercurial have been using this strategy of ignoring new data in the past. For example, when named branch or bookmark where introduced in the past, old client where able to interact with repository using the new repo without too much behavior impact. Not interested. There is already no buy-in from teams that build tools on top of Mercurial for *yet another branching method*. I can promise that your proposals will only set back any progress made so far. This is not the feeling I got at the sprint. Cheers, -- Pierre-Yves David __
Re: Topics [was: news from the topic experiment]
Pierre-Yves David writes: > On 10/15/2016 04:18 PM, Pierre-Yves David wrote: >> >> >> On 10/15/2016 08:47 AM, Yuya Nishihara wrote: >>> On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote: Pierre-Yves David writes: > So, the other branch of that thread made me realised that we cannot do > this "BRANCH:TOPIC" storage in the current "branch" field. > > An important part of topic is to have them fade away when the > changesets > become public. This fading away will be implemented client side (logic > to stop reading the value). If we expose this data to old client who > does not have this logic this means that topic would live as > "BRANCH:TOPIC" forever on old client, breaking them in various way. I don't see that. Currently, we have: - old client cannot see topic at all (making it unusable) - new client can see topics If we move to branchname + flag, we have: - old client can see and update using 'hg update NAME' (extremely valuable) - old client can merge a topic to default (extremely helpful and surprising) - new client will hide those branches Your argument is that old clients will see those branches. That's a much better side-effect than not being able to update at all to a topic branch. >>> >>> I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding >>> "BRANCH" is >>> bad because you can't filter log by "branch(BRANCH)" in old client. > > Exposing topic directly into the branch field means that all the > behavior related to named branch will be broken for old clients once > someone start using topic in the repository. > > > For example, if a team is using the "foo" branch for development, > tracking the head of "foo" is important. Mercurial keeps a set of > behavior user rely on, eg: hg up "foo" works, and with this branch > active, "hg up" or "hg merge" pick the right head. > > Now, let's assume the topic information is part of the "branch" field, > someone in the team start using topic and do some work on the "bar" > topic, their changeset will contains topic informations. For that user, > the topic information will just fade away when pushed to the public > server. The server will not expose that topic information (because the > changeset is public and the server is new), Other team member pulling > with a new client will see the "foo" branch move forward as expected > without mention of the "bar" topic. > However (if the topic information is part of the "branch" field), old > clients pulling from that server will get a different result. Instead of > having "foo" move forward, they will get a new branch "foo:bar". The > branch "foo" will be stuck behind until someone hopefully do work > without topic. Breaking the behavior described earlier. In addition this > new branch might break various other automation that would now refuse to > push a new branch. > > This highlight how important the control of topic life cycle is. Topics > must be able to disappear for public changeset. This is the feature that > allow the rest of the Mercurial work flows to keep working for > immutable changeset. And this requires the meaning of the "branch" field > to stay backward compatible. > As a side note, I would like to emphasize that having advanced users > about to try out topic without poisoning the common well will be > important for adoption. I think your logic is very contrived here. No, branch names don't have to disappear. That's no "a requirement" as you say. What you are suggesting is very over-engineered [1]. Though, it is getting late here and I can respond more tomorrow. > I'm confident we can find interesting solution for the various > inconvenient the old client will see. For example, (random though), we > could not serve topic changesets to old client by default, while still > honoring explicit requests in the form "branch:topic". > > > Mercurial have been using this strategy of ignoring new data in the > past. For example, when named branch or bookmark where introduced in the > past, old client where able to interact with repository using the new > repo without too much behavior impact. Not interested. There is already no buy-in from teams that build tools on top of Mercurial for *yet another branching method*. I can promise that your proposals will only set back any progress made so far. For what it's worth, I've started to work on another repo implementing what Erik suggested. It removes 'stacks' (since that's obviously out of scope) and implements a topic-like branch workflow. So far, it's been a good experiment and requires very little change. I'll post here once I have more feedback. [1] http://xkcd.com/974/ ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Nested Subrepos non-recursive/deferred cloning
This email have many interesting bits, especially: * a bit about avoiding cloning, * a bit about avoiding multiple copy of the same repository, * a bit about tracking dependency. That last one is a complex and dense topic. My reply to it is taking a bit too long. So I'm releasing the answer about the first two bits only to avoid delaying it too long. On 10/28/2016 07:30 PM, Ken Frederickson wrote: On Fri, Oct 28, 2016 at 3:03 AM, Pierre-Yves David wrote: On 10/23/2016 08:26 PM, Ken Frederickson wrote: Hello, When using subrepos, I frequently get in a situation where nested subrepos result in multiple copies of the same repo. This can cause several headaches, like a hit on sync time, confusion which copy of the redundant repo I'm co-developing, etc. Additionally, it's troubling that cloning of the parent repo fails if the clone of the subrepo fails, which could easily happen if the URL of the subrepo has been altered (i.e. server migration). My solution is to write a custom extension that largely mimics the functionality of subrepos, but does not automatically recursively clone subrepos. Instead, I would make a command that I could execute at each repo level that would pull one or all of its subrepos. My question is: have some of these issues already been considered or partially addressed with more recent subrepo work? Should I contribute to subrepo or should I stick with an independent extension? We recently gained the ability to have both version of binary flag (eg `hg up --check` and `hg up --no-check`. (This is very new and not documented yet). We could use this with the canonical subrepository option and clone to introduce a `hg clone --no-subrepository` to would skip the subrepo clone. This could be extended to other operation What do you think ? Yes I think preventing the automatic recursive clone would go a long way. This would give the user the opportunity to modify the the .hgsub file before the subrepo clone has occurred to point to an alternate url. Personally, I'd also like the ability to clone individual subrepos by name (perhaps by using the path defined in the .hgsub file). Something like 'hg clone -S lib/foo'. And clone them all with something like 'hg clone -S --all'. (I think 'clone' isn't the right command. Maybe 'hg update -S lib/foo'). This is handy when your dependencies differ based on your build configuration and you only need a subset of your subrepos. hg update is taking revision as argument. So it might not be the best place. We could use `hg revert` for this and it would not even need a -S argument. Also, I'm do not think `hg clone` itself is triggering the recursive clone, if I remember correctly, the update after the close is triggering clone of the repository that needs update. So cloning without update (hg clone --noupdate), should get you half the way here. On the practical usage of the feature to avoid redundant copies of repos in the tree, this presents similar workflow challenges to what I describe below. For any repo that would appear more than once in the tree, I would manually avoid cloning it after the first instance and point dependent repos' builds to the one copy. This loses the benefits of automatic update of subrepo hashes and push protection if dependent repos have uncommitted changes. What I want is the ability to have a single copy of repos and still have them track. Did you gave a shot to the "share" extension. A couple of version ago, it gained the ability to use a "clone pool". Any clone of a repository already in the pool will actually be performed as the creation of a new share (a new working copy, sharing the history with other) and an update of the history in the pooled repository. It seems like it could fit your need perfectly. […] The extension I've begun designing will flatten a nested subrepo tree to a two-level tree with a single parent and N child repos. When I child repo depends on another repo, the other repo becomes a peer in the group of child repos. So say libA depends on libB and App depends on libA and libB. Cloning App will clone libA and libB into a dependency pool. When libA attempts to clone it's own copy of libB, it will instead be linked with the existing copy of libB which is peer to it in the dependency pool. Like subrepos, if I have working changes to libB, both libA and App will not be able to commit. When I commit libB's changes, both libA and App's .hgsubstate (or equivalent) will be updated. You should have a look at the "share pool" mechanism I pointed above it seems like it could a large part of your usecase here. […] Cheers, -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Topics [was: news from the topic experiment]
On 10/15/2016 04:18 PM, Pierre-Yves David wrote: On 10/15/2016 08:47 AM, Yuya Nishihara wrote: On Fri, 14 Oct 2016 13:13:56 -0700, Sean Farley wrote: Pierre-Yves David writes: So, the other branch of that thread made me realised that we cannot do this "BRANCH:TOPIC" storage in the current "branch" field. An important part of topic is to have them fade away when the changesets become public. This fading away will be implemented client side (logic to stop reading the value). If we expose this data to old client who does not have this logic this means that topic would live as "BRANCH:TOPIC" forever on old client, breaking them in various way. I don't see that. Currently, we have: - old client cannot see topic at all (making it unusable) - new client can see topics If we move to branchname + flag, we have: - old client can see and update using 'hg update NAME' (extremely valuable) - old client can merge a topic to default (extremely helpful and surprising) - new client will hide those branches Your argument is that old clients will see those branches. That's a much better side-effect than not being able to update at all to a topic branch. I agree seeing "BRANCH:TOPIC" is a better side-effect, but hiding "BRANCH" is bad because you can't filter log by "branch(BRANCH)" in old client. Exposing topic directly into the branch field means that all the behavior related to named branch will be broken for old clients once someone start using topic in the repository. For example, if a team is using the "foo" branch for development, tracking the head of "foo" is important. Mercurial keeps a set of behavior user rely on, eg: hg up "foo" works, and with this branch active, "hg up" or "hg merge" pick the right head. Now, let's assume the topic information is part of the "branch" field, someone in the team start using topic and do some work on the "bar" topic, their changeset will contains topic informations. For that user, the topic information will just fade away when pushed to the public server. The server will not expose that topic information (because the changeset is public and the server is new), Other team member pulling with a new client will see the "foo" branch move forward as expected without mention of the "bar" topic. However (if the topic information is part of the "branch" field), old clients pulling from that server will get a different result. Instead of having "foo" move forward, they will get a new branch "foo:bar". The branch "foo" will be stuck behind until someone hopefully do work without topic. Breaking the behavior described earlier. In addition this new branch might break various other automation that would now refuse to push a new branch. This highlight how important the control of topic life cycle is. Topics must be able to disappear for public changeset. This is the feature that allow the rest of the Mercurial work flows to keep working for immutable changeset. And this requires the meaning of the "branch" field to stay backward compatible. As a side note, I would like to emphasize that having advanced users about to try out topic without poisoning the common well will be important for adoption. I'm confident we can find interesting solution for the various inconvenient the old client will see. For example, (random though), we could not serve topic changesets to old client by default, while still honoring explicit requests in the form "branch:topic". Mercurial have been using this strategy of ignoring new data in the past. For example, when named branch or bookmark where introduced in the past, old client where able to interact with repository using the new repo without too much behavior impact. Cheers, -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] match: adding support for repository-root-based globs
> On Oct 28, 2016, at 4:40 AM, Pierre-Yves David > wrote: > > > > On 10/25/2016 09:41 AM, Rodrigo Damazio Bovendorp via Mercurial-devel wrote: >> # HG changeset patch >> # User Rodrigo Damazio Bovendorp >> # Date 1475944120 25200 >> # Sat Oct 08 09:28:40 2016 -0700 >> # Node ID e8454de81600e092f05aa22ecbac32925b70d074 >> # Parent 260af19891f2bed679a662be07d1379bb8207592 >> match: adding support for repository-root-based globs >> >> The broader plan is to add explicit base directories for all patterns: >> === === >> pattern type root-ed cwd-ed any-of-path >> === === >> wildcard rootglob cwdglob anyglob >> regexp rootre cwdre anyre >> raw string rootpath cwdpath anypath >> === === >> (table by foozy) > > The subject seems complicated enough that creating a Plan page seems > relevant. This would help other people to follow what the problem space. > > https://www.mercurial-scm.org/wiki/WriteANewFeaturePlan I’m not sure if it needs a plan page. It strikes me as believable (perhaps even likely?) that rootglob will be the only part of this implemented for a long time, perhaps ever. (Having the whole table makes good sense to me though, because now we’ve though through the future in case it ever comes.) > >> I'm starting by adding rootglob. >> One important characteristic and difference from the older glob types is >> that * will never match recursively, even when the glob is used as an include >> pattern. > > This seems a bit strange to me. Given that the current glob matcher is > already not recursive, why don't we work on an alternative non recursive -I > flag instead? That means we’ll have a new flag that alters the behavior of existing matchers in subtle ways. It also requires cooperation from every command that we want to add new globbing features to, including extensions, whereas if we can add a couple of new atoms (as outlined in the proposal from foozy) we get consistent behavior across all matchers. It’s a mistake that existing matchers have a recursive * behavior with --include, but it’s too late to change that. As such, I’d much rather have this proposal as currently stated. > Cheers, > > -- > Pierre-Yves David > ___ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
mercurial@30241: 12 new changesets (12 on stable)
12 new changesets (12 on stable) in mercurial: http://selenic.com/repo/hg//rev/46a0203dfb89 changeset: 30230:46a0203dfb89 branch: stable user:Yuya Nishihara date:Wed Oct 26 22:50:06 2016 +0900 summary: tests: run "cwd was removed" test only if cwd can actually be removed http://selenic.com/repo/hg//rev/741e5d7f282d changeset: 30231:741e5d7f282d branch: stable user:Yuya Nishihara date:Sun Oct 23 14:05:23 2016 +0900 summary: templater: do not use index.partialmatch() directly to calculate shortest() http://selenic.com/repo/hg//rev/362740e05460 changeset: 30232:362740e05460 branch: stable user:Yuya Nishihara date:Tue Oct 25 21:49:30 2016 +0900 summary: templater: use unfiltered changelog to calculate shortest() at constant time http://selenic.com/repo/hg//rev/3afde791dce1 changeset: 30233:3afde791dce1 branch: stable user:Mads Kiilerich date:Thu Oct 27 20:06:33 2016 +0200 summary: largefiles: handle that a found standin file doesn't exist when removing it http://selenic.com/repo/hg//rev/34a5f6c66bc5 changeset: 30234:34a5f6c66bc5 branch: stable user:FUJIWARA Katsunori date:Sat Oct 29 02:44:45 2016 +0900 summary: tests: invoke printenv.py via sh -c for test portability http://selenic.com/repo/hg//rev/fe612ab5eeff changeset: 30235:fe612ab5eeff branch: stable user:FUJIWARA Katsunori date:Sat Oct 29 03:04:54 2016 +0900 summary: tests: use "?" to glob both ":" and ";" in output for test portability http://selenic.com/repo/hg//rev/141cb12c0175 changeset: 30236:141cb12c0175 branch: stable user:FUJIWARA Katsunori date:Sat Oct 29 03:08:08 2016 +0900 summary: tests: add test-commit-interactive-curses.t "require tic" for test portability http://selenic.com/repo/hg//rev/94ef2f00b8a4 changeset: 30237:94ef2f00b8a4 branch: stable user:FUJIWARA Katsunori date:Sun Oct 30 06:15:07 2016 +0900 summary: tests: use basic format code "%Y" instead of "%s" for test portability http://selenic.com/repo/hg//rev/9843e3d9f4b6 changeset: 30238:9843e3d9f4b6 branch: stable user:FUJIWARA Katsunori date:Sun Oct 30 06:15:09 2016 +0900 summary: tests: avoid quoting of commit messages for test portability http://selenic.com/repo/hg//rev/6e04f4ec4875 changeset: 30239:6e04f4ec4875 branch: stable user:FUJIWARA Katsunori date:Sun Oct 30 06:15:09 2016 +0900 summary: tests: put temporary file outside the working directory for test portability http://selenic.com/repo/hg//rev/8237c3359db5 changeset: 30240:8237c3359db5 branch: stable user:FUJIWARA Katsunori date:Sun Oct 30 06:15:09 2016 +0900 summary: tests: test preserving execbit changes at amending only on execbit platform http://selenic.com/repo/hg//rev/cac4ca036dff changeset: 30241:cac4ca036dff branch: stable bookmark:@ tag: tip user:Mads Kiilerich date:Mon Oct 31 13:43:48 2016 +0100 summary: httppeer: make __del__ access to self.urlopener more safe -- Repository URL: http://selenic.com/repo/hg/ ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH stable] tag: clarify warning about making a tag on a branch head
# HG changeset patch
# User Nathan Goldbaum
# Date 1477951952 18000
# Mon Oct 31 17:12:32 2016 -0500
# Branch stable
# Node ID ec11aa398c707b524b7e15994b5bf74bba6bc119
# Parent 69ffbbe73dd03df0d1a00bdb2bc083fdb73ede09
tag: clarify warning about making a tag on a branch head
Currently the warning is ambiguous about whether the new tag (possibly specified
via --rev) is being added on a branch head or whether the working directory is
based on a branch head. Clarify the error message to eliminate this ambiguity.
diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -7077,7 +7077,8 @@ def tag(ui, repo, name1, *names, **opts)
raise error.Abort(_('uncommitted merge'))
bheads = repo.branchheads()
if not opts.get('force') and bheads and p1 not in bheads:
-raise error.Abort(_('not at a branch head (use -f to force)'))
+raise error.Abort(_('working directory is not at a branch head
'
+'(use -f to force)'))
r = scmutil.revsingle(repo, rev_).node()
if not message:
diff --git a/tests/test-tag.t b/tests/test-tag.t
--- a/tests/test-tag.t
+++ b/tests/test-tag.t
@@ -109,7 +109,7 @@ tagging on a non-head revision
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg tag -l localblah
$ hg tag "foobar"
- abort: not at a branch head (use -f to force)
+ abort: working directory is not at a branch head (use -f to force)
[255]
$ hg tag -f "foobar"
$ cat .hgtags
@@ -339,7 +339,7 @@ tagging on null rev
$ hg up null
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
$ hg tag nullrev
- abort: not at a branch head (use -f to force)
+ abort: working directory is not at a branch head (use -f to force)
[255]
$ hg init empty
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH WIP] help: show help content for disabled extension
On Sat, Oct 22, 2016 at 1:38 PM, Yuya Nishihara wrote: > On Fri, 21 Oct 2016 09:13:11 -0400, timeless wrote: >> Have we considered supporting `hg help churn.churn` where the first >> churn is a (possibly) disabled extension name, and the second is the >> name of a command within that extension? > > Not yet? Well working on issue5228, I found that we support something like `hg help qrecord` and if record extension is not enabled it will say, 'qrecord' is provided by the following extension: recordcommands to interactively select changes for commit/qrefresh (DEPRECATED) (use 'hg help extensions' for information on enabling extensions) We support saying that this command is provided by the following extension, if the extension is disabled. >> I'm not saying we should do this right away, but I can see some >> advantages to being able to support it later... > > Perhaps that would be somewhat useful, but would be much complicated compared > to just parsing a module doc. That's why I think we should simply fix the > issue5228 first. > > https://bz.mercurial-scm.org/show_bug.cgi?id=5228 > ___ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH stable] httppeer: make __del__ access to self.urlopener more safe
On Mon, 31 Oct 2016 13:44:13 +0100, Mads Kiilerich wrote: > # HG changeset patch > # User Mads Kiilerich > # Date 1477917828 -3600 > # Mon Oct 31 13:43:48 2016 +0100 > # Branch stable > # Node ID 13b1ef724b8c5c22f9234f62b9d9a583655ce87e > # Parent 69ffbbe73dd03df0d1a00bdb2bc083fdb73ede09 > httppeer: make __del__ access to self.urlopener more safe Looks good. httppeer.__init__() could be skipped entirely. Queued, thanks. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH stable] httppeer: make __del__ access to self.urlopener more safe
# HG changeset patch # User Mads Kiilerich # Date 1477917828 -3600 # Mon Oct 31 13:43:48 2016 +0100 # Branch stable # Node ID 13b1ef724b8c5c22f9234f62b9d9a583655ce87e # Parent 69ffbbe73dd03df0d1a00bdb2bc083fdb73ede09 httppeer: make __del__ access to self.urlopener more safe Some errors could in some cases show unfortunate scary and confusing warnings from the httppeer delstructors: abort: nodename nor servname provided, or not known Exception AttributeError: "'httpspeer' object has no attribute 'urlopener'" in > ignored``` To mute that, take 7b15dd9125b3 to the next level and use getattr in __del__. diff --git a/mercurial/httppeer.py b/mercurial/httppeer.py --- a/mercurial/httppeer.py +++ b/mercurial/httppeer.py @@ -63,8 +63,9 @@ class httppeer(wireproto.wirepeer): self.requestbuilder = urlreq.request def __del__(self): -if self.urlopener: -for h in self.urlopener.handlers: +urlopener = getattr(self, 'urlopener', None) +if urlopener: +for h in urlopener.handlers: h.close() getattr(h, "close_all", lambda : None)() ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
