Social presence 2023

2023-07-11 Thread Anton Shestakov

Hey all,

This is just a quick email to start a brainstorming thread about our 
public presence on the Internet.


We have some presence at the moment, e.g.

https://wiki.mercurial-scm.org/SocialMedia
https://wiki.mercurial-scm.org/ProjectInfrastructure

I'm not sure how active these accounts are, and I have no urge to even 
dip my toes into big corporate social networks for some reason.


But, watching all these news about current Twitter and Reddit "executive 
decisions" made me think about maybe getting an official account on 
federated social networks aka the Fediverse. For example, there's 
fosstodon.org for microblogging (e.g. announcing releases) and 
programming.dev for general discussions (e.g. user support and sharing 
blog posts, etc). Of course, if anyone has a better suited instance in 
mind (self-hosting??), feel free to suggest.


For an example microblogging style of content, here's Heptapod:

https://fosstodon.org/@heptapod

Finally, if we do get some official accounts on the Fediverse, I 
personally wouldn't mind posting something there occasionally and/or be 
a backup moderator just in case, but unfortunately I'm not in the 
position to be in charge of those accounts at this moment.

___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Testing an RC of evolve 11.0.0 and topic 1.0.0

2023-02-14 Thread Anton Shestakov

14.02.2023 17:20, Georges Racinet пишет:
Internally, Heptapod relies on the `branch:topic` syntax, more 
specifically as keys in the branchmap. Well, it relies on lots of 
Mercurial and evolve internals (I dare not say APIs).


In 11.0.0rc0+ branchmap will have keys in the "branch//namespace/topic" 
format. There are more places when you'll see this format instead of 
branch name alone now and we intend to use it locally more widely in future.


The good news here is that simply replacing `:` with `//` makes all the 
tests pass. Given the full coverage, I'm fairly confident that there are 
no other problems, as far as we're only talking about the compatibility 
itself with (server-side) Heptapod.


Make sure you look though examples for formatfqbn() and parsefqbn() in 
topic/common.py.


Overall it looks like an unnecessary complication to try and support 
both syntaxes in Heptapod. I'm more comfortable keeping my compatibility 
fixes around and making the switch once Evolve 11.0.0 is released.


My questions:

- will there be in 11.0 a way for clients to specify topic namespaces? 


There is a debug-topic-namespace command that will let you do it.

- what will happen when topic namespaces are fully implemented and users 
with, say hg-evolve 12.0, push to a server with hg-evolve 10.5? Can I 
simulate that from a Python interpreter already?


Topic namespaces are not understood by older clients, so those clients 
will simply see branches+topics only. So if you had branch "b", topic 
namespace "tns" and topic "t", then newer clients would see "b//tns/t", 
and older clients would see "b:t". It's been deemed to be safe, because 
the worst case is you're using new version and trying to push "b//foo/t" 
and older server has "b//bar/t": you won't be able to push freely 
because server sees them both as "b:t".


Simulating locally is not yet possible, but adding that (for testing 
purposes) is on my plate for the final release.



- will 11.0 be required to support the upcoming Mercurial 6.4?


Probably not evolve version 11.0.0 specifically, since it's planned to 
be released before hg 6.4, but we will release a bugfix/maintenance 
release with support for new versions of Mercurial. So most likely, 
11.0.1 will support hg 6.4. Although if we see hg 6.4rc0 soon, then we 
can support that version in 11.0.0.

___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Testing an RC of evolve 11.0.0 and topic 1.0.0

2023-02-08 Thread Anton Shestakov

30.01.2023 19:24, Anton Shestakov пишет:
The release candidate is coming out in the next few days, and the final 
feature release will most likely be ready in about 2 weeks after that. 
During these 2 weeks you can reach out to us and tell if you notice 
something being broken, and we'll obviously try and fix it before the 
final release.


And after numerous compatibility fixes and tweaks (and some delays) 
11.0.0rc0 is finally out!


If you want to test it, you might need to specify the new version 
explicitly to install it, e.g. `pip install hg-evolve==11.0.0rc0`.


If you spot any issues with it, feel free to contact the developers in 
your preferred way (e.g. via bugzilla, #mercurial or #hg-evolve on 
libera.chat or replying to this email on list or to me directly).

___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Testing an RC of evolve 11.0.0 and topic 1.0.0

2023-02-06 Thread Anton Shestakov

04.02.2023 22:56, Uwe Brauer пишет:

Maybe we have a misunderstanding here.

I don't mean the result

  hg branches

I meant that sometimes

  hg log (with my template, I am not going to post here would give me)

◍  changeset: 674:5c76f339a2eb
│  tag:   tip
│  Branch:year-2022-23//git-manual
│  Author:Uwe Brauer 
│  Date:  Sat, 04 Feb 2023 18:45:29 +0100
│  Topic: git-manual
│  Phase: draft
│  Summary:   Old text out, tutorias programadas
│


Well, this is most likely not done by evolve/topic extensions. As I 
said, no released version of evolve or topic uses '//' as a separator in 
the UI yet. What's more, even the default branch (not released) doesn't 
override `hg log` entries to be in this format. What versions of evolve 
and topic are you using, after all?


There's one case where topic extension (briefly and internally) uses 
'//' to separate branch and topic, and it's used for 
experimental.topic.linear-merge implementation. If it's visible in the 
UI during normal operations, this could be a bug that needs to be fixed.


However, from what I know now, this really seem to be your custom log 
template that's doing it.



And that I found very annoying.


Why?
___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Testing an RC of evolve 11.0.0 and topic 1.0.0

2023-02-04 Thread Anton Shestakov

04.02.2023 14:56, Uwe Brauer пишет:



03.02.2023 00:34, Uwe Brauer пишет:



By "this" do you mean "branch:topic" or "branch//topic"?


I meant "branch//topic"

So can I switch the new namespace feature of, if I don't like it?


That depends on what you think "the new namespace feature" is. If you 
don't want to use topic namespaces, then you don't have to. There's a 
default namespace that will not be shown (similar to default branch or 
empty topic).


On the other hand, if you want to forever use "branch:topic" format that 
was never intended to be usable (e.g. hg up "branch:topic" doesn't 
necessarily do what you expect), then you can use old versions of evolve 
and topic.



What version of evolve do you have?


I think it is 10.1. It has been quite some time I installed it, and I
don't recall whether I did it by pip or compiled it myself.

Eye balling the help, I can find a command to determine evolve's version


It's `hg version -v` and no, 10.1.0 definitely didn't have any topic 
namespaces. The new "branch//namespace/topic" format at the moment is 
only used in current default branch of evolve, which is not yet 
released, but will be a part of the upcoming release candidate (i.e. rc 
of 11.0.0). Also 10.1.0 is nowhere near "the current evolve version", 
it's from 2+ years ago, topic namespaces were still only in the plans.


But the old "branch:topic" format was used in certain places like `hg 
branches`, where it shouldn't be. This will likely change in the future, 
since the UI part of topic namespaces feature is still being worked on.

___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Testing an RC of evolve 11.0.0 and topic 1.0.0

2023-02-04 Thread Anton Shestakov

03.02.2023 00:34, Uwe Brauer пишет:

Hello, users of Mercurial, Evolve and/or Topic!
We're planning to release a feature release candidate of evolve and
topic extensions that contains an implementation of a concept that was
in the plans for quite some time: topic namespaces (the name could
change, if we find something better)

But we did change some things in the UI. Remember seeing
"branch:topic" format in `hg branches`? Well, it was a temporary
implementation detail. With the implementation of topic namespaces we
introduce a more thought-out way to represent branches plus topics. In
this new format, topic namespaces become sort of a glue for all things
related to (named) branching, e.g. this is what you'd see in hg log:



   branch//namespace/topic



or, if you don't set topic namespace:



   branch//topic


I use topics quite extensively, but my collaborators not.
Strangely enough I see this structure sometimes in the current evolve version 
(and it annoys me quite a bit). Will this behavior be configurable (ie. Switch 
it off)?


By "this" do you mean "branch:topic" or "branch//topic"?

What version of evolve do you have?


BTW what are the minimum requirements for this evolve version you describe.


At the moment we're planning to still support Mercurial 4.8.


Would be hg 5.2 ok (either compiled with python 3.5 or 2.7)?


It would, but you should upgrade.
___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Are you using evolve.serveronly and serverminitopic extensions?

2023-01-30 Thread Anton Shestakov

Hello, users of Mercurial, Evolve and/or Topic!

Some of you may be using the following server-only extensions: 
evolve.serveronly and serverminitopic, that live in the same repo as 
regular evolve extension: https://www.mercurial-scm.org/repo/evolve


These extensions were used by Bitbucket when it still supported 
Mercurial, because they were very lightweight and supported the minimum 
logic required for proper changeset exchange and obsmarker discovery 
(for example), but without any extra bits like new hg commands in CLI.


Back in the day, people chose these extensions because in theory they 
would have lower risk of breaking things; after all, evolve and topic do 
have some experimental features. However, it currently seems that 
evolve.serveronly and serverminitopic aren't tested (neither by our test 
suite nor by the users) as extensively as the main evolve and topic 
extensions, which in the recent years became much more polished after 
being test-driven daily in real circumstances on real projects by both 
the developers and the users (who are also developers sometimes (:).


So if you use evolve.serveronly and serverminitopic, we would really 
suggest you to switch to evolve and topic on the server side. The good 
news is that this shouldn't have any adverse effects on your setup.


If you have any questions, don't hesitate to ask them in a response to 
this email, or starting a separate thread on this mailing list, or 
emailing me directly. Also we're on IRC: #mercurial on libera.chat, 
https://www.mercurial-scm.org/wiki/IRC


The bad news is that while preparing a feature release candidate, we 
noticed that it's no longer viable to add features and cover them by 
tests in multiple extensions, so we're going to deprecate 
evolve.serveronly and serverminitopic in the coming release candidate 
and then REMOVE BOTH extensions in the coming feature release.


If you really cannot switch to the main extensions in your server setup, 
you will still be able to use the old extensions from evolve 10.5.3, but 
obviously they won't support newer features that are coming soon.


If you're interested in testing the new features from the release 
candidate (and/or knowing why this feature release needs an rc at all, 
which is unusual for evolve), I have sent another email to this mailing 
list about evolve 11.0.0 and topic 1.0.0.

___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


Testing an RC of evolve 11.0.0 and topic 1.0.0

2023-01-30 Thread Anton Shestakov

Hello, users of Mercurial, Evolve and/or Topic!

We're planning to release a feature release candidate of evolve and 
topic extensions that contains an implementation of a concept that was 
in the plans for quite some time: topic namespaces (the name could 
change, if we find something better) 
https://www.mercurial-scm.org/wiki/TopicPlan#sub_branches.2C_namespacing_and_representation


In short, topic namespaces are trying to fix one of our major UX flaws: 
branches can continue to be used for release management, and topics can 
still be used for implementing features, but now there would be 
something for organizing topics into wider concepts. Topic namespaces, 
just like topics, are designed to go away when you publish your commits, 
and we tried to make them as unobtrusive as possible, to not get in the 
way of current workflows. There is a default topic namespace that will 
not clutter the UI, and users can keep using only branches and topics as 
usual.


But we did change some things in the UI. Remember seeing "branch:topic" 
format in `hg branches`? Well, it was a temporary implementation detail. 
With the implementation of topic namespaces we introduce a more 
thought-out way to represent branches plus topics. In this new format, 
topic namespaces become sort of a glue for all things related to (named) 
branching, e.g. this is what you'd see in hg log:


  branch//namespace/topic

or, if you don't set topic namespace:

  branch//topic

In the future, we're going to support providing branches, topic 
namespaces (if you decide to use them) and topics in this format to all 
commands where it makes sense.


Now, what these topic namespaces are aimed at? Among other things, topic 
namespaces are supposed to help users manage topics; their own and other 
users'. Previously, some people were already using username as a prefix 
for their topic names - this was an ad-hoc implementation of separation 
and/or ownership of work, and now with topic namespaces it's becoming 
more standardized and user-friendly.


Here are more details on what aspects of workflow topic namespaces try 
to improve (taken from the wiki page linked above):


* on the client side, they could be used to safeguard history-rewriting 
operations and in particular avoid conflicting with other people's work


* code hosting providers and forges could map topic namespaces to their 
user or team concepts, and hence ultimately to their permission model


* they could be used to narrow user view and exchange to the part that 
are relevant to them by default


Although the UI didn't change much, and a big part of the planned 
features is not implemented yet, the changes that are included are quite 
extensive. We have changed a significant part of topic's representation 
locally and over the wire during the exchange. Given the scale of these 
changes we encourage people to test this release candidate. That would 
definitely help us pinpoint real issues that we didn't foresee during 
the planning and the development. It could also possibly give you some 
ideas how to integrate topic namespaces into your workflows early.


The release candidate is coming out in the next few days, and the final 
feature release will most likely be ready in about 2 weeks after that. 
During these 2 weeks you can reach out to us and tell if you notice 
something being broken, and we'll obviously try and fix it before the 
final release. That being said, topic namespaces are here to stay, 
although maybe under a different name and with some changes after 
testing in real circumstances.

___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12626: revlog: use %d to format int instead of %lu (issue6565)

2022-05-17 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  The issue says gcc warns that the data types don't match. I couldn't reproduce
  the warning locally for some reason, but this patch shouldn't break things.
  Maybe %lu was simply a copy-paste error from 6b1eae313b2f 

  (https://phab.mercurial-scm.org/D10625).

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12626

AFFECTED FILES
  mercurial/cext/revlog.c

CHANGE DETAILS

diff --git a/mercurial/cext/revlog.c b/mercurial/cext/revlog.c
--- a/mercurial/cext/revlog.c
+++ b/mercurial/cext/revlog.c
@@ -497,7 +497,7 @@
if (self->format_version != format_v1) {
PyErr_Format(PyExc_RuntimeError,
 "version header should go in the docket, not the "
-"index: %lu",
+"index: %d",
 header);
return NULL;
}



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12622: doc: use an absolute path in sys.path

2022-05-10 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  The idea and rationale is similar to https://phab.mercurial-scm.org/D12599
  (landed as 1b6e381521c5 
).

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12622

AFFECTED FILES
  doc/check-seclevel.py

CHANGE DETAILS

diff --git a/doc/check-seclevel.py b/doc/check-seclevel.py
--- a/doc/check-seclevel.py
+++ b/doc/check-seclevel.py
@@ -9,7 +9,7 @@
 
 # import from the live mercurial repo
 os.environ['HGMODULEPOLICY'] = 'py'
-sys.path.insert(0, "..")
+sys.path.insert(0, os.path.abspath(".."))
 from mercurial import demandimport
 
 demandimport.enable()



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12621: check-py3-compat: use an absolute path in sys.path

2022-05-10 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  The idea and rationale is similar to https://phab.mercurial-scm.org/D12599
  (landed as 1b6e381521c5 
).

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12621

AFFECTED FILES
  contrib/check-py3-compat.py

CHANGE DETAILS

diff --git a/contrib/check-py3-compat.py b/contrib/check-py3-compat.py
--- a/contrib/check-py3-compat.py
+++ b/contrib/check-py3-compat.py
@@ -76,7 +76,7 @@
 # specified. When running as test-check-py3-compat.t, we technically
 # would import the correct paths, but it's cleaner to have both cases
 # use the same import logic.
-sys.path.insert(0, '.')
+sys.path.insert(0, os.getcwd())
 
 for f in sys.argv[1:]:
 with warnings.catch_warnings(record=True) as warns:



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12620: tests: make sure .js files stay in ASCII encoding (issue6559)

2022-05-09 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12620

AFFECTED FILES
  tests/test-check-encoding.t

CHANGE DETAILS

diff --git a/tests/test-check-encoding.t b/tests/test-check-encoding.t
new file mode 100644
--- /dev/null
+++ b/tests/test-check-encoding.t
@@ -0,0 +1,26 @@
+#require test-repo hg10
+
+  $ . "$TESTDIR/helpers-testrepo.sh"
+
+  $ cat > $TESTTMP/check_ascii.py < import sys
+  > for file_path in sys.argv[1:]:
+  > with open(file_path, 'br') as f:
+  > try:
+  > f.read().decode('ascii', 'strict')
+  > except UnicodeDecodeError as exc:
+  > print('%s: %s' % (file_path, exc))
+  > EOF
+
+There are some web servers in the wild that can serve static files with an
+incorrect encoding (e.g. https://bz.mercurial-scm.org/show_bug.cgi?id=6559).
+One way to prevent any issues is to not use any non-ASCII characters, e.g.
+URL-encoding them or using HTML entities.
+
+check charset of all tracked files ending in .js
+
+  $ cd "`dirname "$TESTDIR"`"
+
+  $ testrepohg locate 'set:**.js' \
+  > 2>/dev/null \
+  > | xargs "$PYTHON" $TESTTMP/check_ascii.py



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12598: tests: make sure .js files stay in ASCII encoding (issue6559)

2022-05-02 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12598

AFFECTED FILES
  tests/test-check-encoding.t

CHANGE DETAILS

diff --git a/tests/test-check-encoding.t b/tests/test-check-encoding.t
new file mode 100644
--- /dev/null
+++ b/tests/test-check-encoding.t
@@ -0,0 +1,17 @@
+#require test-repo hg10
+
+  $ . "$TESTDIR/helpers-testrepo.sh"
+
+There are some web servers in the wild that can serve static files with an
+incorrect encoding (e.g. https://bz.mercurial-scm.org/show_bug.cgi?id=6559).
+One way to prevent any issues is to not use any non-ASCII characters, e.g.
+URL-encoding them or using HTML entities.
+
+check charset of all tracked files ending in .js except vendored dependencies
+
+  $ cd "`dirname "$TESTDIR"`"
+
+  $ testrepohg locate 'set:**.js' \
+  > 2>/dev/null \
+  > | xargs file -i \
+  > | grep -v 'charset=us-ascii'



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12597: followlines: don't put Unicode directly into the .js file (issue6559)

2022-05-02 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Apparently some web server setups may serve this file in a different encoding
  than UTF-8, and that results in visual garbage in the followlines button that
  renders for every line in a file. So instead of using this Unicode character 
in
  UTF-8 we can encode it as \u2212. Or, to be more explicit, we can use 
  HTML entity, which resolves into exactly that character.
  
  Since now we're using innerHTML property to set the minus part of the button,
  let's use it to set the plus part as well (even though the plus sign was plain
  ASCII). A wise man once said "A foolish consistency is the hobgob... eh,
  whatever." Throw a brick at me if this makes things worse.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12597

AFFECTED FILES
  mercurial/templates/static/followlines.js

CHANGE DETAILS

diff --git a/mercurial/templates/static/followlines.js 
b/mercurial/templates/static/followlines.js
--- a/mercurial/templates/static/followlines.js
+++ b/mercurial/templates/static/followlines.js
@@ -50,13 +50,13 @@
 btn.classList.add('btn-followlines');
 var plusSpan = document.createElement('span');
 plusSpan.classList.add('followlines-plus');
-plusSpan.textContent = '+';
+plusSpan.innerHTML = '';
 btn.appendChild(plusSpan);
 var br = document.createElement('br');
 btn.appendChild(br);
 var minusSpan = document.createElement('span');
 minusSpan.classList.add('followlines-minus');
-minusSpan.textContent = '−';
+minusSpan.innerHTML = '';
 btn.appendChild(minusSpan);
 return btn;
 }



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12589: tests: fix misspelling of supersede

2022-04-27 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12589

AFFECTED FILES
  tests/test-push-checkheads-partial-C1.t
  tests/test-push-checkheads-partial-C2.t
  tests/test-push-checkheads-pruned-B2.t
  tests/test-push-checkheads-pruned-B3.t
  tests/test-push-checkheads-pruned-B5.t
  tests/test-push-checkheads-pruned-B8.t
  tests/test-push-checkheads-superceed-A1.t
  tests/test-push-checkheads-superceed-A2.t
  tests/test-push-checkheads-superceed-A3.t
  tests/test-push-checkheads-superceed-A4.t
  tests/test-push-checkheads-superceed-A5.t
  tests/test-push-checkheads-superceed-A6.t
  tests/test-push-checkheads-superceed-A7.t
  tests/test-push-checkheads-superceed-A8.t
  tests/test-push-checkheads-unpushed-D4.t
  tests/test-push-checkheads-unpushed-D5.t

CHANGE DETAILS

diff --git a/tests/test-push-checkheads-unpushed-D5.t 
b/tests/test-push-checkheads-unpushed-D5.t
--- a/tests/test-push-checkheads-unpushed-D5.t
+++ b/tests/test-push-checkheads-unpushed-D5.t
@@ -17,8 +17,8 @@
 ..
 .. new-state:
 ..
-.. * 1 new branch superceeding the head of the old-2-changesets-branch,
-.. * 1 new changesets on the old-1-changeset-branch superceeding the base of 
the other
+.. * 1 new branch superseding the head of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superseding the base of 
the other
 ..
 .. expected-result:
 ..
diff --git a/tests/test-push-checkheads-unpushed-D4.t 
b/tests/test-push-checkheads-unpushed-D4.t
--- a/tests/test-push-checkheads-unpushed-D4.t
+++ b/tests/test-push-checkheads-unpushed-D4.t
@@ -17,8 +17,8 @@
 ..
 .. new-state:
 ..
-.. * 1 new branch superceeding the base of the old-2-changesets-branch,
-.. * 1 new changesets on the old-1-changeset-branch superceeding the head of 
the other
+.. * 1 new branch superseding the base of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superseding the head of 
the other
 ..
 .. expected-result:
 ..
diff --git a/tests/test-push-checkheads-superceed-A8.t 
b/tests/test-push-checkheads-superceed-A8.t
--- a/tests/test-push-checkheads-superceed-A8.t
+++ b/tests/test-push-checkheads-superceed-A8.t
@@ -8,7 +8,7 @@
 
 This case is part of a series of tests checking this behavior.
 
-Category A: simple case involving a branch being superceeded by another.
+Category A: simple case involving a branch being superseded by another.
 TestCase 8: single-changeset branch indirect rewrite
 
 .. old-state:
diff --git a/tests/test-push-checkheads-superceed-A7.t 
b/tests/test-push-checkheads-superceed-A7.t
--- a/tests/test-push-checkheads-superceed-A7.t
+++ b/tests/test-push-checkheads-superceed-A7.t
@@ -8,7 +8,7 @@
 
 This case is part of a series of tests checking this behavior.
 
-Category A: simple case involving a branch being superceeded by another.
+Category A: simple case involving a branch being superseded by another.
 TestCase 7: multi-changeset branch, split on multiple other, (head on its own 
branch), same number of head
 
 .. old-state:
@@ -17,8 +17,8 @@
 ..
 .. new-state:
 ..
-.. * 1 new branch superceeding the head of the old-2-changesets-branch,
-.. * 1 new changesets on the old-1-changeset-branch superceeding the base of 
the other
+.. * 1 new branch superseding the head of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superseding the base of 
the other
 ..
 .. expected-result:
 ..
diff --git a/tests/test-push-checkheads-superceed-A6.t 
b/tests/test-push-checkheads-superceed-A6.t
--- a/tests/test-push-checkheads-superceed-A6.t
+++ b/tests/test-push-checkheads-superceed-A6.t
@@ -8,7 +8,7 @@
 
 This case is part of a series of tests checking this behavior.
 
-Category A: simple case involving a branch being superceeded by another.
+Category A: simple case involving a branch being superseded by another.
 TestCase 6: multi-changeset branch, split on multiple other, (base on its own 
branch), same number of head
 
 .. old-state:
@@ -17,8 +17,8 @@
 ..
 .. new-state:
 ..
-.. * 1 new branch superceeding the base of the old-2-changesets-branch,
-.. * 1 new changesets on the old-1-changeset-branch superceeding the head of 
the other
+.. * 1 new branch superseding the base of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superseding the head of 
the other
 ..
 .. expected-result:
 ..
diff --git a/tests/test-push-checkheads-superceed-A5.t 
b/tests/test-push-checkheads-superceed-A5.t
--- a/tests/test-push-checkheads-superceed-A5.t
+++ b/tests/test-push-checkheads-superceed-A5.t
@@ -8,7 +8,7 @@
 
 This case is part of a series of tests checking this behavior.
 
-Category A: simple case involving a branch being superceeded by another.
+Category A: simple case involving a branch being superseded by another.
 TestCase 5: New changeset as parent of the successor
 
 .. old-state:
diff --git 

D12195: obsolete: don't use os.stat in repo.obsstore.__nonzero__ if it's static HTTP

2022-02-15 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  If a repo is accessed via static HTTP, then we obviously can't use os.stat() 
to
  just peek at the file size. Let's download the entire file to check its size.
  Yes, this feels wasteful, but:
  
  1. If we're cloning or pulling a repo from a static HTTP server, we need the 
contents of the obsstore anyway.
  
  2. Implementing statichttpvfs.stat() that uses HEAD will result in one more 
request to a static-only HTTP server, which is already slow. Also parsing a 
response to a HEAD request to construct os.stat_result is pretty hacky. There's 
also a question of the remote server properly supporting HEAD method and 
reporting at least file size.
  
  3. Implementing statichttpvfs.stat() that uses GET is pretty much the same 
thing as we do here, except we can't even cache the response easily, unlike 
simply accessing obsstore._data, which is @propertycache'd.
  
  Importing statichttprepo locally to avoid circular import.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12195

AFFECTED FILES
  mercurial/obsolete.py

CHANGE DETAILS

diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -575,11 +575,16 @@
 return len(self._all)
 
 def __nonzero__(self):
+from . import statichttprepo
+if isinstance(self.repo, statichttprepo.statichttprepository):
+# If repo is accessed via static HTTP, then we can't use os.stat()
+# to just peek at the file size.
+return self._data > 1
 if not self._cached('_all'):
 try:
 return self.svfs.stat(b'obsstore').st_size > 1
 except OSError as inst:
-if inst.errno not in (errno.ENOENT, errno.EINVAL):
+if inst.errno != errno.ENOENT:
 raise
 # just build an empty _all list if no obsstore exists, which
 # avoids further stat() syscalls



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12157: scmutil: obsrevs is already a frozenset

2022-02-09 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12157

AFFECTED FILES
  mercurial/scmutil.py

CHANGE DETAILS

diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -366,9 +366,7 @@
 obsrevs = obsolete.getrevs(repo, b'obsolete')
 if not cl.filteredrevs and not obsrevs:
 return None
-# TODO: obsrevs should be a frozenset, but right now obsolete.getrevs()
-# may return a set, which is not a hashable type.
-key = (maxrev, hash(cl.filteredrevs), hash(frozenset(obsrevs)))
+key = (maxrev, hash(cl.filteredrevs), hash(obsrevs))
 else:
 if not cl.filteredrevs:
 return None



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12156: obsolete: always return frozensets from obsolete.getrevs()

2022-02-09 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  getrevs function already returns an empty frozenset when there is no obsstore,
  but let's make sure to return a frozenset in any case. This makes it possible
  to use the result of this function as a dict key or provide it to hash()
  built-in function without any conversions.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12156

AFFECTED FILES
  mercurial/obsolete.py

CHANGE DETAILS

diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -940,8 +940,7 @@
 getnode = repo.changelog.node
 notpublic = _mutablerevs(repo)
 isobs = repo.obsstore.successors.__contains__
-obs = {r for r in notpublic if isobs(getnode(r))}
-return obs
+return frozenset(r for r in notpublic if isobs(getnode(r)))
 
 
 @cachefor(b'orphan')
@@ -959,14 +958,14 @@
 if p in obsolete or p in unstable:
 unstable.add(r)
 break
-return unstable
+return frozenset(unstable)
 
 
 @cachefor(b'suspended')
 def _computesuspendedset(repo):
 """the set of obsolete parents with non obsolete descendants"""
 suspended = repo.changelog.ancestors(getrevs(repo, b'orphan'))
-return {r for r in getrevs(repo, b'obsolete') if r in suspended}
+return frozenset(r for r in getrevs(repo, b'obsolete') if r in suspended)
 
 
 @cachefor(b'extinct')
@@ -998,7 +997,7 @@
 # we have a public predecessor
 bumped.add(rev)
 break  # Next draft!
-return bumped
+return frozenset(bumped)
 
 
 @cachefor(b'contentdivergent')
@@ -1025,7 +1024,7 @@
 divergent.add(rev)
 break
 toprocess.update(obsstore.predecessors.get(prec, ()))
-return divergent
+return frozenset(divergent)
 
 
 def makefoldid(relation, user):



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12138: branchmap: split a long condition in branchcache.validfor(), add comments

2022-02-07 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12138

AFFECTED FILES
  mercurial/branchmap.py

CHANGE DETAILS

diff --git a/mercurial/branchmap.py b/mercurial/branchmap.py
--- a/mercurial/branchmap.py
+++ b/mercurial/branchmap.py
@@ -352,17 +352,25 @@
 return filename
 
 def validfor(self, repo):
-"""Is the cache content valid regarding a repo
+"""check that cache contents are valid for (a subset of) this repo
 
-- False when cached tipnode is unknown or if we detect a strip.
-- True when cache is up to date or a subset of current repo."""
+- False when the order of changesets changed or if we detect a strip.
+- True when cache is up-to-date for the current repo or its subset."""
 try:
-return (self.tipnode == repo.changelog.node(self.tiprev)) and (
-self.filteredhash
-== scmutil.filteredhash(repo, self.tiprev, needobsolete=True)
-)
+node = repo.changelog.node(self.tiprev)
 except IndexError:
+# changesets were stripped and now we don't even have enough to
+# find tiprev
 return False
+if self.tipnode != node:
+# tiprev doesn't correspond to tipnode: repo was stripped, or this
+# repo has a different order of changesets
+return False
+tiphash = scmutil.filteredhash(repo, self.tiprev, needobsolete=True)
+# hashes don't match if this repo view has a different set of filtered
+# revisions (e.g. due to phase changes) or obsolete revisions (e.g.
+# history was rewritten)
+return self.filteredhash == tiphash
 
 def _branchtip(self, heads):
 """Return tuple with last open head in heads and false,



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12135: branchmap: don't add branch entries if there are no heads

2022-02-06 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  We definitely don't want any empty entries to be present in repo.branchmap()
  just for the sake of not breaking test-notify.t.
  
  No test changes required because the previous patch made notify extension to
  not raise any tracebacks in case of RepoLookupErrors.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12135

AFFECTED FILES
  mercurial/branchmap.py

CHANGE DETAILS

diff --git a/mercurial/branchmap.py b/mercurial/branchmap.py
--- a/mercurial/branchmap.py
+++ b/mercurial/branchmap.py
@@ -519,7 +519,7 @@
 #   checks can be skipped. Otherwise, the ancestors of the
 #   "uncertain" set are removed from branchheads.
 #   This computation is heavy and avoided if at all possible.
-bheads = self._entries.setdefault(branch, [])
+bheads = self._entries.get(branch, [])
 bheadset = {cl.rev(node) for node in bheads}
 uncertain = set()
 for newrev in sorted(newheadrevs):
@@ -562,8 +562,8 @@
 if floorrev <= max(uncertain):
 ancestors = set(cl.ancestors(uncertain, floorrev))
 bheadset -= ancestors
-bheadrevs = sorted(bheadset)
-self[branch] = [cl.node(rev) for rev in bheadrevs]
+if bheadset:
+self[branch] = [cl.node(rev) for rev in sorted(bheadset)]
 tiprev = max(newheadrevs)
 if tiprev > ntiprev:
 ntiprev = tiprev



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12134: notify: don't produce errors if a revision is not found

2022-02-06 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Notify extension has a way to only subscribe to a specific revset, such as
  "branch(foo)". Before this patch, when there was no branch with that name, it
  would produce a traceback saying "unknown revision: foo". With this patch it
  would no longer do that, and instead it'll assume there are no revisions that
  match this revset. I think this patch is an improvement in general, but 
there's
  a reason I'm sending it now.
  
  test-notify.t has a test case where it obsoletes the only revision on a 
branch,
  and previously that wouldn't produce any complications, because head
  computation wasn't obsolescence-aware. Now if the only revision on a branch is
  obsolete, repo should not see that branch at all.
  
  That branch will still be present in branchcache (with an empty list of
  revisions) until the next patch.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12134

AFFECTED FILES
  hgext/notify.py

CHANGE DETAILS

diff --git a/hgext/notify.py b/hgext/notify.py
--- a/hgext/notify.py
+++ b/hgext/notify.py
@@ -435,7 +435,10 @@
 if spec is None:
 subs.add(sub)
 continue
-revs = self.repo.revs(b'%r and %d:', spec, ctx.rev())
+try:
+revs = self.repo.revs(b'%r and %d:', spec, ctx.rev())
+except error.RepoLookupError:
+continue
 if len(revs):
 subs.add(sub)
 continue



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12121: obsolete: don't import from .node twice

2022-01-31 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  See d55b71393907 
.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12121

AFFECTED FILES
  mercurial/obsolete.py

CHANGE DETAILS

diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -73,10 +73,6 @@
 import struct
 
 from .i18n import _
-from .node import (
-bin,
-hex,
-)
 from .pycompat import getattr
 from .node import (
 bin,



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12120: dagop: don't import nullrev from .node twice

2022-01-31 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  See 59fa3890d40a 
.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12120

AFFECTED FILES
  mercurial/dagop.py

CHANGE DETAILS

diff --git a/mercurial/dagop.py b/mercurial/dagop.py
--- a/mercurial/dagop.py
+++ b/mercurial/dagop.py
@@ -9,7 +9,6 @@
 
 import heapq
 
-from .node import nullrev
 from .thirdparty import attr
 from .node import nullrev
 from . import (



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12097: branchmap: skip obsolete revisions while computing heads

2022-01-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  It's time to make this part of core Mercurial obsolescence-aware.
  
  Not considering obsolete revisions when computing heads is clearly what
  Mercurial should do. But there are a couple of small issues:
  
  - Let's say tip of the repo is obsolete. There are two ways of finding tiprev 
for branchcache (both are in use): looking at input data for update() and 
looking at computed heads after update(). Previously, repo tip would be tiprev 
of the branchcache. With this patch, an obsolete revision can no longer be 
tiprev. And depending on what way we use for finding tiprev (input data vs 
computed heads) we'll get a different result. This is relevant when recomputing 
cache key from cache contents, and may lead to updating cache for obsolete 
revisions multiple times.
  
  - If all commits on a branch are obsolete, the branchcache will include that 
branch, but the list of heads will be empty (e.g. `if not heads`). This is 
currently required for notify extension (and test-notify.t to pass), because 
notify doesn't handle revsets in its subscription config very well and will 
throw an error if e.g. a branch doesn't exist.
  
  - Static HTTP repo clones try to stat() a non-existent obsstore file. The 
issue is that we now care about obsolescence during clone, but statichttprepo 
for some reason uses wrong vfs for obsstore. It's not a statichttpvfs, but a 
regular local one. I couldn't find the cause of this behavior yet. During one 
of the operations on obsstore, we're trying to stat() the file, but in static 
HTTP case we provide a literal URL to the obsstore file on the remote as if it 
were a local file path. It's very silly. On windows it actually results in a 
failure in test-static-http.t.
  
  The first issue is going to be addressed in a series dedicated to making sure
  branchcache is properly and timely written on disk (it wasn't perfect even
  before this patch, but there aren't enough tests to demonstrate that). The
  second issue will be addressed in a future patch for notify extension. And the
  third will be partially addressed in a later patch in this series and properly
  fixed in a future patch to make sure obsstore is accessed using statichttpvfs.
  
  filteredhash() grows a keyword argument to make sure that branchcache is also
  invalidated when there are new obsolete revisions in its repo view. This way
  the on-disk cache format is unchanged and compatible between versions 
(although
  it will obviously be recomputed when switching versions before/after this 
patch
  and the repo has obsolete revisions).
  
  There's one test that uses plain `hg up` without arguments while updated to a
  pruned commit. To make this test pass, simply return current working directory
  parent. Later in this series this code will be replaced by what prune command
  does: updating to the closest non-obsolete ancestor.
  
  Test changes:
  
  test-branch-change.t: update branch head and cache update message. The head of
  default listed in hg heads is changed because revision 2 was rewritten as 7,
  and 1 is the closest ancestor on the same branch, so it's the head of default
  now.
  
  The cache invalidation message appears now because of the cache hash change,
  since we're now accounting for obsolete revisions. Here's some context:
  
  "served.hidden" repo filter means everything is visible (no filtered
  revisions), so before this series branch2-served.hidden file would not contain
  any cache hash, only revnum and node. Now it also has a hash when there are
  obsolete changesets in the repo. The command that the message appears for is
  changing branch of 5 and 6, which are now obsolete, so the cache hash changes.
  
  In general, when cache is simply out-of-date, it can be updated using the old
  version as a base. But if cache hash differs, then the cache for that
  particular repo filter is recomputed (at least with the current
  implementation). This is what happens here.
  
  test-obsmarker-template.t: the pull reports 2 heads changed, but after that 
the
  repo correctly sees only 1. The new message could be better, but it's still an
  improvement over the previous one where hg pull suggested merging with an
  obsolete revision.
  
  test-obsolete.t: we can see these revisions in hg log --hidden, but they
  shouldn't be considered heads even with --hidden.
  
  test-rebase-obsolete{,2}.t: there were new heads created previously after
  making new orphan changesets, but they weren't detected. Now we are properly
  detecting and reporting them.
  
  test-rebase-obsolete4.t: there's only one head now because the other head is
  pruned and was falsely reported before.
  
  test-static-http.t: add obsstore to the list of requested files. This file
  doesn't exist on the remotes, but clients want it anyway (they get 404). This
  is fine, because there are other 

D12098: discovery: port _postprocessobsolete() changes from evolve, add tests

2022-01-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Let's make this function obsolescence-aware as well. Now we check that
  revisions are not obsolete first, and only then check that they are going to 
be
  common after exchange.
  
  The tests make sure that rewriting changesets doesn't confuse head 
computation.
  They rely on experimental.single-head-per-branch feature to show that remote
  correctly sees the expected result (i.e. either aborts the push or allows it 
to
  succeed). They are ported from evolve as well.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12098

AFFECTED FILES
  mercurial/discovery.py
  tests/test-single-head-obsolescence-named-branch-A1.t
  tests/test-single-head-obsolescence-named-branch-A2.t
  tests/test-single-head-obsolescence-named-branch-A3.t
  tests/test-single-head-obsolescence-named-branch-A4.t
  tests/test-single-head-obsolescence-named-branch-A5.t
  tests/testlib/push-checkheads-util.sh

CHANGE DETAILS

diff --git a/tests/testlib/push-checkheads-util.sh 
b/tests/testlib/push-checkheads-util.sh
--- a/tests/testlib/push-checkheads-util.sh
+++ b/tests/testlib/push-checkheads-util.sh
@@ -41,4 +41,10 @@
 mkcommit A0
 cd ..
 hg clone server client
+
+if [ "$1" = "single-head" ]; then
+echo >> "server/.hg/hgrc" "[experimental]"
+echo >> "server/.hg/hgrc" "# enforce a single name per branch"
+echo >> "server/.hg/hgrc" "single-head-per-branch = yes"
+fi
 }
diff --git a/tests/test-single-head-obsolescence-named-branch-A5.t 
b/tests/test-single-head-obsolescence-named-branch-A5.t
new file mode 100644
--- /dev/null
+++ b/tests/test-single-head-obsolescence-named-branch-A5.t
@@ -0,0 +1,108 @@
+=
+Testing single head enforcement: Case A-5
+=
+
+A repository is set to only accept a single head per name (typically named
+branch). However, obsolete changesets can make this enforcement more
+complicated, because they can be kept visible by other changeset on other
+branch.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: Involving obsolescence
+TestCase 5: Obsoleting a merge reveals two heads
+
+.. old-state:
+..
+.. * 3 changesets on branch default (2 on their own branch + 1 merge)
+.. * 1 changeset on branch Z (children of the merge)
+..
+.. new-state:
+..
+.. * 2 changesets on branch default (merge is obsolete) each a head
+.. * 1 changeset on branch Z keeping the merge visible
+..
+.. expected-result:
+..
+.. * 2 heads detected (because we skip the merge)
+..
+.. graph-summary:
+..
+..   C ●  (branch Z)
+.. |
+..   M ⊗
+.. |\
+..   A ● ● B
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+  $ cat >> $HGRCPATH << EOF
+  > [command-templates]
+  > log = "{node|short} [{branch}] ({phase}): {desc}\n"
+  > EOF
+
+Test setup
+--
+
+  $ mkdir A5
+  $ cd A5
+  $ setuprepos single-head
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B0
+  created new head
+  $ hg merge
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  (branch merge, don't forget to commit)
+  $ hg ci -m 'M0'
+  $ hg branch Z
+  marked working directory as branch Z
+  (branches are permanent and global, did you want a bookmark?)
+  $ mkcommit C0
+  $ hg push --new-branch
+  pushing to $TESTTMP/A5/server
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 3 changesets with 2 changes to 2 files
+  $ hg debugobsolete `getid "desc(M0)"` --record-parents
+  1 new obsolescence markers
+  obsoleted 1 changesets
+  1 new orphan changesets
+  $ hg heads
+  61c95483cc12 [Z] (draft): C0
+  74ff5441d343 [default] (draft): B0
+  8aaa48160adc [default] (draft): A0
+  $ hg log -G --hidden
+  @  61c95483cc12 [Z] (draft): C0
+  |
+  x14d3d4d41d1a [default] (draft): M0
+  |\
+  | o  74ff5441d343 [default] (draft): B0
+  | |
+  o |  8aaa48160adc [default] (draft): A0
+  |/
+  o  1e4be0697311 [default] (public): root
+  
+
+Actual testing
+--
+
+(force push to make sure we get the changeset on the remote)
+
+  $ hg push -r 'desc("C0")' --force
+  pushing to $TESTTMP/A5/server
+  searching for changes
+  no changes found
+  transaction abort!
+  rollback completed
+  abort: rejecting multiple heads on branch "default"
+  (2 heads: 8aaa48160adc 74ff5441d343)
+  [255]
diff --git a/tests/test-single-head-obsolescence-named-branch-A4.t 
b/tests/test-single-head-obsolescence-named-branch-A4.t
new file mode 100644
--- /dev/null
+++ b/tests/test-single-head-obsolescence-named-branch-A4.t
@@ -0,0 +1,117 @@

D12100: obsolete: make sure windows tests pass when stat() is given a URL

2022-01-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  This is a band-aid for test-static-http.t breakage on windows.
  
  On windows this exception is not ENOENT, but EINVAL (because of `:` symbol, 
for
  example).
  
  The real issue here is not using statichttpvfs for accessing obsstore, but I
  didn't find the root cause of that yet.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12100

AFFECTED FILES
  mercurial/obsolete.py

CHANGE DETAILS

diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -583,7 +583,7 @@
 try:
 return self.svfs.stat(b'obsstore').st_size > 1
 except OSError as inst:
-if inst.errno != errno.ENOENT:
+if inst.errno not in (errno.ENOENT, errno.EINVAL):
 raise
 # just build an empty _all list if no obsstore exists, which
 # avoids further stat() syscalls



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12099: destutil: if wdp is obsolete, update to the closest non-obsolete ancestor

2022-01-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  As the original comments suggest, using prune as a model here was an existing
  idea, and now this patch implements it.
  
  I think it would be even better to do what solveobswdp() from evolve does (in
  short, it allows to update to a successor of the closest ancestor even if that
  ancestor is obsolete), but that is outside of this series' scope.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12099

AFFECTED FILES
  mercurial/destutil.py
  tests/test-update-branches.t

CHANGE DETAILS

diff --git a/tests/test-update-branches.t b/tests/test-update-branches.t
--- a/tests/test-update-branches.t
+++ b/tests/test-update-branches.t
@@ -696,9 +696,8 @@
   (commit or update --clean to discard changes)
   [255]
 
-Test that we don't crash when updating from a pruned changeset (i.e. has no
-successors). Behavior should probably be that we update to the first
-non-obsolete parent but that will be decided later.
+Test that we update to the closest non-obsolete ancestor when updating from a
+pruned changeset (i.e. that has no successors)
   $ hg id --debug -r 2
   bd10386d478cd5a9faf2e604114c8e6da62d3889
   $ hg up --quiet 0
@@ -706,21 +705,18 @@
   $ hg debugobsolete bd10386d478cd5a9faf2e604114c8e6da62d3889
   1 new obsolescence markers
   obsoleted 1 changesets
+  $ hg log -r '_destupdate()'
+  1:0786582aa4b1 1 (no-eol)
   $ hg up
-  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
-
-Test experimental revset support
-
-  $ hg log -r '_destupdate()'
-  2:bd10386d478c 2 (no-eol)
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
 Test that boolean flags allow --no-flag specification to override [defaults]
   $ cat >> $HGRCPATH < [defaults]
   > update = --check
   > EOF
-  $ hg co 2
+  $ hg co 1
   abort: uncommitted changes
   [20]
-  $ hg co --no-check 2
+  $ hg co --no-check 1
   0 files updated, 0 files merged, 0 files removed, 0 files unresolved
diff --git a/mercurial/destutil.py b/mercurial/destutil.py
--- a/mercurial/destutil.py
+++ b/mercurial/destutil.py
@@ -65,9 +65,8 @@
 # replaced changesets: same as divergent except we know there
 # is no conflict
 #
-# pruned changeset: no update is done; though, we could
-# consider updating to the first non-obsolete parent,
-# similar to what is current done for 'hg prune'
+# pruned changeset: update to the closest non-obsolete ancestor,
+# similar to what 'hg prune' currently does
 
 if successors:
 # flatten the list here handles both divergent (len > 1)
@@ -77,11 +76,15 @@
 # get the max revision for the given successors set,
 # i.e. the 'tip' of a set
 node = repo.revs(b'max(%ln)', successors).first()
-if bookmarks.isactivewdirparent(repo):
-movemark = repo[b'.'].node()
 else:
-# TODO: copy hg prune logic
-node = repo[b'.'].node()
+p1 = p1.p1()
+while p1.obsolete():
+p1 = p1.p1()
+node = p1.node()
+
+if node is not None and bookmarks.isactivewdirparent(repo):
+movemark = repo[b'.'].node()
+
 return node, movemark, None
 
 



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D12092: interfaces: add missing caches kwarg of localrepo.updatecaches()

2022-01-27 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Added to localrepo: in 1337bfaa88ca 
, 
added to the interface: now.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12092

AFFECTED FILES
  mercurial/interfaces/repository.py

CHANGE DETAILS

diff --git a/mercurial/interfaces/repository.py 
b/mercurial/interfaces/repository.py
--- a/mercurial/interfaces/repository.py
+++ b/mercurial/interfaces/repository.py
@@ -1787,7 +1787,7 @@
 DANGEROUS.
 """
 
-def updatecaches(tr=None, full=False):
+def updatecaches(tr=None, full=False, caches=None):
 """Warm repo caches."""
 
 def invalidatecaches():



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Evolve mini-sprint January 7th

2022-01-03 Thread Anton Shestakov
Happy New Year everyone! I hope you celebrated enough to enjoy the 
holiday season to the fullest, but not enough to forget that there's a 
sprint this week, Friday, January 7th.



Hello everyone,

Keeping the tradition of monthly mini-sprints related to all things
Mercurial, the next one will be dedicated to changeset evolution and
evolve extension (topic extension too). It will be held on Friday,
January 7th. There's no specific schedule for the day, it will be open
for any evolve-related questions and discussions, and most of the
developers should be available during daytime in Europe (let's say
roughly UTC+1).

The mini-sprint is a good chance for developers, contributors and users
alike to discuss anything related to evolution and Mercurial. Bringing
up a pet peeve, submitting a patch or a feature request, asking a
question — it's a free-for-all. Core developers will also be talking
about upcoming features and bug fixes.

Anyone is welcome to join #hg-evolve and/or #mercurial on libera.chat:
https://web.libera.chat/?channel=#hg-evolve,#mercurial (and not just on
January 7th).

We'll also have impromptu video-calls. Topics and links for those will
be posted on the IRC channels during the day.

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Evolve mini-sprint January 7th

2021-12-27 Thread Anton Shestakov
Hello everyone,

Keeping the tradition of monthly mini-sprints related to all things
Mercurial, the next one will be dedicated to changeset evolution and
evolve extension (topic extension too). It will be held on Friday,
January 7th. There's no specific schedule for the day, it will be open
for any evolve-related questions and discussions, and most of the
developers should be available during daytime in Europe (let's say
roughly UTC+1).

The mini-sprint is a good chance for developers, contributors and users
alike to discuss anything related to evolution and Mercurial. Bringing
up a pet peeve, submitting a patch or a feature request, asking a
question — it's a free-for-all. Core developers will also be talking
about upcoming features and bug fixes.

Anyone is welcome to join #hg-evolve and/or #mercurial on libera.chat:
https://web.libera.chat/?channel=#hg-evolve,#mercurial (and not just on
January 7th).

We'll also have impromptu video-calls. Topics and links for those will
be posted on the IRC channels during the day.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Evolve mini-sprint October 8th

2021-10-08 Thread Anton Shestakov
Hello again,

We have started the mini-sprint!

As I've mentioned earlier, any questions about evolution are fine to
ask either in our IRC (see the quoted email for links) or in the VC.

Link to the VC: https://meet.jit.si/evolve-mini-sprint-10.4.0

Questions about Mercurial in general are also fine. Status updates will
be posted to the #hg-evolve or #mercurial channels on libera.chat.

> Hello everyone,
> 
> Keeping the tradition of monthly mini-sprints related to all things
> Mercurial, the next one will be dedicated to changeset evolution and
> evolve extension (topic extension too). It will be held on Friday,
> October 8th. There's no specific schedule for the day, it will be open
> for any evolve-related questions and discussions, and most of
> developers should be available during daytime in Europe (let's say
> roughly UTC+2).
> 
> The mini-sprint is a good chance for developers, contributors and users
> alike to discuss anything related to evolution and Mercurial. Bringing
> up a pet peeve, submitting a patch or a feature request, asking a
> question — it's a free-for-all. Core developers will also be talking
> about upcoming features and bug fixes.
> 
> Anyone is welcome to join #hg-evolve and/or #mercurial on libera.chat:
> https://web.libera.chat/?channel=#hg-evolve,#mercurial (and not just on
> October 8th)
> 
> We'll also have impromptu video-calls. Topics and links for those will
> be posted on the IRC channels.

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Evolve mini-sprint October 8th

2021-09-29 Thread Anton Shestakov
On Wed, 29 Sep 2021 08:02:09 -0700
Martin von Zweigbergk via Mercurial-devel
 wrote:

> I think organizing a "real" sprint in 10 days is not really realistic,
> > though I agree that we should think about the next Mercurial sprint.
> >  
> Do you know if anyone has started thinking about that?

The idea was floating around since Octobus decided to hold monthly
sprints, but that was summer, when everyone was on vacation. Now a
full-blown Mercurial sprint could be put in rotation. I think early
December would be a good time for that.

Not pointing to anyone in particular, but I'm sure there would be
people who wouldn't mind organizing such a sprint.

As for this sprint, yeah, it's going to be a mini one (a day), mostly
focusing on evolve and evolution things (which could still be related
to core Mercurial too, obviously).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Evolve mini-sprint October 8th

2021-09-28 Thread Anton Shestakov
Hello everyone,

Keeping the tradition of monthly mini-sprints related to all things
Mercurial, the next one will be dedicated to changeset evolution and
evolve extension (topic extension too). It will be held on Friday,
October 8th. There's no specific schedule for the day, it will be open
for any evolve-related questions and discussions, and most of
developers should be available during daytime in Europe (let's say
roughly UTC+2).

The mini-sprint is a good chance for developers, contributors and users
alike to discuss anything related to evolution and Mercurial. Bringing
up a pet peeve, submitting a patch or a feature request, asking a
question — it's a free-for-all. Core developers will also be talking
about upcoming features and bug fixes.

Anyone is welcome to join #hg-evolve and/or #mercurial on libera.chat:
https://web.libera.chat/?channel=#hg-evolve,#mercurial (and not just on
October 8th)

We'll also have impromptu video-calls. Topics and links for those will
be posted on the IRC channels.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D11223: obsolete: disable other evolution config options if createmarkers is off

2021-07-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  We used to raise an abort in this case, but recent changes to local clone
  command (377d8fc20e34 
) 
resulted in destrepo both caring about
  experimental.evolution config options and not initializing extensions.
  
  So imagine if you had evolve and allowdivergence enabled in your ~/.hgrc. 
Local
  clone stopped working after 377d8fc20e34 
 
because evolve sets
  experimental.evolution=all, but only on srcrepo, for destrepo the extension is
  not initialized. It's possible to make local cloning work by initializing
  extensions for destrepo in some cases, but in other cases (e.g. 
allowdivergence
  in ~/.hgrc, evolve extension in original-repo/.hg/hgrc) it would still fail.
  
  In a discussion with Pierre-Yves David it was decided to simply force other
  evolution options to be false if createmarkers is not enabled.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D11223

AFFECTED FILES
  mercurial/obsolete.py
  tests/test-clone.t

CHANGE DETAILS

diff --git a/tests/test-clone.t b/tests/test-clone.t
--- a/tests/test-clone.t
+++ b/tests/test-clone.t
@@ -580,6 +580,24 @@
   3 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ rm -r ua
 
+Local clones don't get confused by unusual experimental.evolution options
+
+  $ hg clone \
+  >   --config experimental.evolution=allowunstable,allowdivergence,exchange \
+  >   a ua
+  updating to branch default
+  3 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ rm -r ua
+
+  $ hg clone \
+  >   --config experimental.evolution.createmarkers=no \
+  >   --config experimental.evolution.allowunstable=yes \
+  >   --config experimental.evolution.allowdivergence=yes \
+  >   --config experimental.evolution.exchange=yes \
+  >   a ua
+  updating to branch default
+  3 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ rm -r ua
 
 Test clone with special '@' bookmark:
   $ cd a
diff --git a/mercurial/obsolete.py b/mercurial/obsolete.py
--- a/mercurial/obsolete.py
+++ b/mercurial/obsolete.py
@@ -144,20 +144,16 @@
 """Returns dicts showing state of obsolescence features."""
 
 createmarkersvalue = _getoptionvalue(repo, createmarkersopt)
-unstablevalue = _getoptionvalue(repo, allowunstableopt)
-divergencevalue = _getoptionvalue(repo, allowdivergenceopt)
-exchangevalue = _getoptionvalue(repo, exchangeopt)
-
-# createmarkers must be enabled if other options are enabled
-if (
-unstablevalue or divergencevalue or exchangevalue
-) and not createmarkersvalue:
-raise error.Abort(
-_(
-b"'createmarkers' obsolete option must be enabled "
-b"if other obsolete options are enabled"
-)
-)
+if createmarkersvalue:
+unstablevalue = _getoptionvalue(repo, allowunstableopt)
+divergencevalue = _getoptionvalue(repo, allowdivergenceopt)
+exchangevalue = _getoptionvalue(repo, exchangeopt)
+else:
+# if we cannot create obsolescence markers, we shouldn't exchange them
+# or perform operations that lead to instability or divergence
+unstablevalue = False
+divergencevalue = False
+exchangevalue = False
 
 return {
 createmarkersopt: createmarkersvalue,



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D11221: rebase: use obsolete.isenabled() to check for experimental.allowdivergence

2021-07-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: martinvonz.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Now that obsolete.isenabled() can also check if divergence is allowed, let's
  use it for consistency. Other experimental.evolution options are already
  checked via this function.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D11221

AFFECTED FILES
  hgext/rebase.py

CHANGE DETAILS

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -362,10 +362,7 @@
 skippedset = set(self.obsolete_with_successor_in_destination)
 skippedset.update(self.obsolete_with_successor_in_rebase_set)
 _checkobsrebase(self.repo, self.ui, obsoleteset, skippedset)
-allowdivergence = self.ui.configbool(
-b'experimental', b'evolution.allowdivergence'
-)
-if allowdivergence:
+if obsolete.isenabled(self.repo, obsolete.allowdivergenceopt):
 self.obsolete_with_successor_in_rebase_set = set()
 else:
 for rev in self.repo.revs(
@@ -1652,7 +1649,7 @@
 successors in destination or no non-obsolete successor.
 """
 # Obsolete node with successors not in dest leads to divergence
-divergenceok = ui.configbool(b'experimental', b'evolution.allowdivergence')
+divergenceok = obsolete.isenabled(repo, obsolete.allowdivergenceopt)
 divergencebasecandidates = rebaseobsrevs - rebaseobsskipped
 
 if divergencebasecandidates and not divergenceok:



To: av6, martinvonz, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D11222: fix: use obsolete.isenabled() to check for experimental.allowdivergence

2021-07-28 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Now that obsolete.isenabled() can also check if divergence is allowed, let's
  use it for consistency. Other experimental.evolution options are already
  checked via this function.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D11222

AFFECTED FILES
  hgext/fix.py

CHANGE DETAILS

diff --git a/hgext/fix.py b/hgext/fix.py
--- a/hgext/fix.py
+++ b/hgext/fix.py
@@ -147,6 +147,7 @@
 mdiff,
 merge,
 mergestate as mergestatemod,
+obsolete,
 pycompat,
 registrar,
 rewriteutil,
@@ -451,10 +452,7 @@
 """Aborts if the revision shouldn't be replaced with a fixed one."""
 if ctx.obsolete():
 # It would be better to actually check if the revision has a successor.
-allowdivergence = ui.configbool(
-b'experimental', b'evolution.allowdivergence'
-)
-if not allowdivergence:
+if not obsolete.isenabled(repo, obsolete.allowdivergenceopt):
 raise error.Abort(
 b'fixing obsolete revision could cause divergence'
 )



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D10948: exchange: use "served" repo filter to guess what the server will publish

2021-07-03 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Previously, the second push in the added test would say "push would publish 2
  changesets" because _checkpublish() was considering secret changesets to be
  "pushable" when push command had a --rev argument.
  
  Without --rev argument to push command, we already filter the repo properly.

REPOSITORY
  rHG Mercurial

BRANCH
  stable

REVISION DETAIL
  https://phab.mercurial-scm.org/D10948

AFFECTED FILES
  mercurial/exchange.py
  tests/test-phases-exchange.t

CHANGE DETAILS

diff --git a/tests/test-phases-exchange.t b/tests/test-phases-exchange.t
--- a/tests/test-phases-exchange.t
+++ b/tests/test-phases-exchange.t
@@ -1592,6 +1592,26 @@
   (use --publish or adjust 'experimental.auto-publish' config)
   [255]
 
+trying to push a secret changeset doesn't confuse auto-publish
+
+  $ hg phase --secret --force
+  test-debug-phase: move rev 0: 1 -> 2
+  test-debug-phase: move rev 1: 1 -> 2
+
+  $ hg push --config experimental.auto-publish=abort
+  pushing to $TESTTMP/auto-publish-orig
+  abort: push would publish 1 changesets
+  (use --publish or adjust 'experimental.auto-publish' config)
+  [255]
+  $ hg push -r . --config experimental.auto-publish=abort
+  pushing to $TESTTMP/auto-publish-orig
+  abort: push would publish 1 changesets
+  (use --publish or adjust 'experimental.auto-publish' config)
+  [255]
+
+  $ hg phase --draft
+  test-debug-phase: move rev 1: 2 -> 1
+
 --publish flag makes push succeed
 
   $ hg push -r '.^' --publish --config experimental.auto-publish=abort
diff --git a/mercurial/exchange.py b/mercurial/exchange.py
--- a/mercurial/exchange.py
+++ b/mercurial/exchange.py
@@ -184,6 +184,10 @@
 published = repo.filtered(b'served').revs(b'not public()')
 else:
 published = repo.revs(b'::%ln - public()', pushop.revs)
+# we want to use pushop.revs in the revset even if they themselves are
+# secret, but we don't want to have anything that the server won't see
+# in the result of this expression
+published &= repo.filtered(b'served')
 if published:
 if behavior == b'warn':
 ui.warn(



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8619: tests: skip pyflakes for selectors2.py

2020-06-06 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  The current version (2.2.0) correctly detects one issue:
  
mercurial/thirdparty/selectors2.py:335:40 '...'.format(...) has unused 
arguments at position(s): 1
  
  But we're not interested in fixing lint errors in third-party code, so there.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8619

AFFECTED FILES
  tests/test-check-pyflakes.t

CHANGE DETAILS

diff --git a/tests/test-check-pyflakes.t b/tests/test-check-pyflakes.t
--- a/tests/test-check-pyflakes.t
+++ b/tests/test-check-pyflakes.t
@@ -18,6 +18,7 @@
   > -X mercurial/pycompat.py -X contrib/python-zstandard \
   > -X mercurial/thirdparty/cbor \
   > -X mercurial/thirdparty/concurrent \
+  > -X mercurial/thirdparty/selectors2.py \
   > -X mercurial/thirdparty/zope \
   > 2>/dev/null \
   > | xargs $PYTHON -m pyflakes 2>/dev/null | "$TESTDIR/filterpyflakes.py"



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8618: tests: adjust to the new format in pyflakes output

2020-06-06 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  According to the pyflakes' NEWS.rst, the default output format changed
  recently:
  
2.2.0 (2020-04-08)
- Include column information in error messages
  
  So the lines now read:
  
contrib/perf.py:149:15 undefined name 'xrange'
mercurial/hgweb/server.py:427:13 undefined name 'reload'
mercurial/util.py:2862:24 undefined name 'file'

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8618

AFFECTED FILES
  tests/test-check-pyflakes.t

CHANGE DETAILS

diff --git a/tests/test-check-pyflakes.t b/tests/test-check-pyflakes.t
--- a/tests/test-check-pyflakes.t
+++ b/tests/test-check-pyflakes.t
@@ -9,7 +9,7 @@
   > print(undefinedname)
   > EOF
   $ $PYTHON -m pyflakes test.py 2>/dev/null | "$TESTDIR/filterpyflakes.py"
-  test.py:1: undefined name 'undefinedname'
+  test.py:1:* undefined name 'undefinedname' (glob)
   
   $ cd "`dirname "$TESTDIR"`"
 
@@ -21,8 +21,8 @@
   > -X mercurial/thirdparty/zope \
   > 2>/dev/null \
   > | xargs $PYTHON -m pyflakes 2>/dev/null | "$TESTDIR/filterpyflakes.py"
-  contrib/perf.py:*: undefined name 'xrange' (glob) (?)
-  mercurial/hgweb/server.py:*: undefined name 'reload' (glob) (?)
-  mercurial/util.py:*: undefined name 'file' (glob) (?)
-  mercurial/encoding.py:*: undefined name 'localstr' (glob) (?)
+  contrib/perf.py:*:* undefined name 'xrange' (glob) (?)
+  mercurial/hgweb/server.py:*:* undefined name 'reload' (glob) (?)
+  mercurial/util.py:*:* undefined name 'file' (glob) (?)
+  mercurial/encoding.py:*:* undefined name 'localstr' (glob) (?)
   



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8617: tests: consistently use pyflakes as a Python module

2020-06-06 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  We check availability of pyflakes as a module, and also running it for real as
  a module. Only fair to test filterpyflakes.py working correctly when using
  pyflakes as a module too.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8617

AFFECTED FILES
  tests/test-check-pyflakes.t

CHANGE DETAILS

diff --git a/tests/test-check-pyflakes.t b/tests/test-check-pyflakes.t
--- a/tests/test-check-pyflakes.t
+++ b/tests/test-check-pyflakes.t
@@ -8,7 +8,7 @@
   $ cat > test.py < print(undefinedname)
   > EOF
-  $ pyflakes test.py 2>/dev/null | "$TESTDIR/filterpyflakes.py"
+  $ $PYTHON -m pyflakes test.py 2>/dev/null | "$TESTDIR/filterpyflakes.py"
   test.py:1: undefined name 'undefinedname'
   
   $ cd "`dirname "$TESTDIR"`"



To: av6, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8394: revset: implement a simple 'foo#generations' expression

2020-04-10 Thread av6 (Anton Shestakov)
av6 created this revision.
av6 added a reviewer: yuja.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  The result of this expression is equivalent to 'foo#g[:]': all reachable
  ancestors and descendants of a revset foo.
  
  While not very useful functionality on its own, its implementation can be
  tested and revset.relations dict can be easily used by extensions to add other
  non-subscript relations.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8394

AFFECTED FILES
  mercurial/revset.py
  tests/test-revset.t

CHANGE DETAILS

diff --git a/tests/test-revset.t b/tests/test-revset.t
--- a/tests/test-revset.t
+++ b/tests/test-revset.t
@@ -1274,6 +1274,36 @@
   5
   7
 
+test ancestors/descendants relation:
+
+  $ log 'tip#generations'
+  0
+  1
+  2
+  4
+  8
+  9
+
+  $ log '3#g'
+  0
+  1
+  3
+  5
+  6
+  7
+
+  $ hg debugrevspec -p parsed 'tip#g'
+  * parsed:
+  (relation
+(symbol 'tip')
+(symbol 'g'))
+  0
+  1
+  2
+  4
+  8
+  9
+
 test ancestors/descendants relation subscript:
 
   $ log 'tip#generations[0]'
diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -247,7 +247,15 @@
 
 
 def relationset(repo, subset, x, y, order):
-raise error.ParseError(_(b"can't use a relation in this context"))
+# this is pretty basic implementation of 'x#y' operator, still
+# experimental so undocumented. see the wiki for further ideas.
+# https://www.mercurial-scm.org/wiki/RevsetOperatorPlan
+rel = getsymbol(y)
+if rel in relations:
+return relations[rel](repo, subset, x, rel, order)
+
+relnames = [r for r in relations.keys() if len(r) > 1]
+raise error.UnknownIdentifier(rel, relnames)
 
 
 def _splitrange(a, b):
@@ -281,6 +289,11 @@
 return ancdepths, descdepths
 
 
+def generationsrel(repo, subset, x, rel, order):
+z = (b'rangeall', None)
+return generationssubrel(repo, subset, x, rel, z, order)
+
+
 def generationssubrel(repo, subset, x, rel, z, order):
 # TODO: rewrite tests, and drop startdepth argument from ancestors() and
 # descendants() predicates
@@ -2633,6 +2646,11 @@
 b"smartset": rawsmartset,
 }
 
+relations = {
+b"g": generationsrel,
+b"generations": generationsrel,
+}
+
 subscriptrelations = {
 b"g": generationssubrel,
 b"generations": generationssubrel,



To: av6, yuja, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D8393: revset: rename generationsrel() to generationssubrel()

2020-04-10 Thread av6 (Anton Shestakov)
av6 created this revision.
av6 added a reviewer: yuja.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  This highlights that this is an implementation of 'x#y[z]' relation subscript
  operator as opposed to 'x#y' relation operator.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8393

AFFECTED FILES
  mercurial/revset.py

CHANGE DETAILS

diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -281,7 +281,7 @@
 return ancdepths, descdepths
 
 
-def generationsrel(repo, subset, x, rel, z, order):
+def generationssubrel(repo, subset, x, rel, z, order):
 # TODO: rewrite tests, and drop startdepth argument from ancestors() and
 # descendants() predicates
 a, b = getintrange(
@@ -2634,8 +2634,8 @@
 }
 
 subscriptrelations = {
-b"g": generationsrel,
-b"generations": generationsrel,
+b"g": generationssubrel,
+b"generations": generationssubrel,
 }
 
 



To: av6, yuja, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: mercurial.host, the Heptapod commercial service

2020-03-23 Thread Anton Shestakov
On Mon, 23 Mar 2020 10:23:05 -0400
Augie Fackler  wrote:

> > On Mar 22, 2020, at 17:29, Georges Racinet  
> > wrote:
> > 
> > We've already bought that domain name, but as a courtesy to the
> > community, we wanted to ask if there were strong objections to us using
> > it for these purposes.
> > 
> > We'll be giving more details both about the upcoming new Heptapod
> > version and the commercial service in separate messages. In the present
> > one, I wanted to focus on the domain name.
> > 
> > So, what do you think ?  
> 
> I guess I'm kind of -0: it kind of makes it sound like it's "blessed" by the 
> upstream community as _the_ hosting provider to me. I suppose if 
> mercurial.host redirected to some other name for the service that doesn't 
> really bug me, since the name wouldn't just be "mercurial host"?

Or an "index" page, having a list of hosting options from
MercurialHosting wiki page (and/or having a link to said wiki page).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 4 of 4] revset: introduce a 'foo#stack[n]' subscript relation to access stack revisions

2019-09-25 Thread Anton Shestakov
On Wed, 25 Sep 2019 02:48:09 +0200
Pierre-Yves David  wrote:

> On 9/25/19 1:25 AM, Yuya Nishihara wrote:
> > On Tue, 24 Sep 2019 21:16:53 +0200, Pierre-Yves David wrote:  
> >> On 9/23/19 2:58 PM, Yuya Nishihara wrote:  
> >>> On Mon, 23 Sep 2019 10:39:52 +0700, Anton Shestakov wrote:  
> >>>> # HG changeset patch
> >>>> # User Anton Shestakov 
> >>>> # Date 1569139969 -25200
> >>>> #  Sun Sep 22 15:12:49 2019 +0700
> >>>> # Node ID ab8f097abacb8ce0f9cea2bce0924bb2fd3261a2
> >>>> # Parent  07af98a1e730c1ffa6911c9ab2cdcc06d4ffe52d
> >>>> # EXP-Topic stack-object
> >>>> revset: introduce a 'foo#stack[n]' subscript relation to access stack 
> >>>> revisions
> >>>>
> >>>> The idea behind making n = 0 cases special is that stack base should be
> >>>> accessible, but only when users ask for it explicitly.  
> >>>  
> >>>> +def stackrel(repo, subset, x, rel, z, order):
> >>>> +a, b = getintrange(z,
> >>>> +   _('relation subscript must be an integer or a 
> >>>> range'),
> >>>> +   _('relation subscript bounds must be integers'),
> >>>> +   deffirst=None,
> >>>> +   deflast=None)
> >>>> +
> >>>> +s = getset(repo, fullreposet(repo), x)
> >>>> +if not s:
> >>>> +return baseset()
> >>>> +
> >>>> +def getrange(st, a, b):
> >>>> +start = 1 if a is None else a
> >>>> +end = len(st.indexedrevs) if b is None else b + 1  
> >>>
> >>> I feel it's weird that stack[:] doesn't include stack[0].  
> >>
> >> [0] is the "root" of the stack, but not part of it. It is handy to have
> >> it around when one want to insert and initial commit or test thing
> >> without any of the stack changes, however it not part of the stack.
> >>
> >> For example if you want to update all changesets in the stack you could
> >> do `hg metaedit --rev '.#stack[:]' --user foobar`. You don't want to
> >> select s0 it might even be a public changesets.  
> > 
> > I understand that. My point is it may be confusing if foo[:] includes 
> > #foo[0],
> > but #bar[:] doesn't.  
> 
> I suspect we already have a "every namespace behave differently 
> situation". The "generation" namespace is not table indexing ".#g[0]" is 
> ".", and ".#g[X]' might return more than on revision.

Yeah, the problem with handling [0] in this special way is usability.
We do want to access stack base sometimes, but it's also not a part of a
stack. So we obviously can't leave it to users to just write a revset to
pick stack base, but it's also cumbersome to write "foo#s[:] - foo#s[0]"
every time you want to pick the whole stack. Maybe removing subscript
would make it more special (and somewhat less confusing), like
"foo#stack"? That's my only idea so far, and I'm not a fan of it.

> Alternatively, maybe stacks needs a different syntax ?

While we decide that, I've pushed a V2 of this series, it doesn't
include #stack[] (i.e. just patches 2 and 3 of the V1 with feedback
addressed). It's not much, but it will allow me to start making stack
implementation in topic extension use bits of stack in core.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2 V2] stack: take getstack() and turn it into stack class (API)

2019-09-25 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1569138369 -25200
#  Sun Sep 22 14:46:09 2019 +0700
# Node ID 2c9d35029c27f3d0e63afc8f618268f079f337c3
# Parent  763028fc6a69a772cfa03c85262e2b6a439de5ab
# EXP-Topic stack-object
stack: take getstack() and turn it into stack class (API)

Stack used to be just a set of revisions, but it's going to grow more features
and it makes sense to encapsulate them into an object.

One reason we don't make stack class inherit from something like smartset class
(and be an iterable containing stack revisions) is that there's going to be
another property related to revisions and we don't want any ambiguity.

diff --git a/mercurial/destutil.py b/mercurial/destutil.py
--- a/mercurial/destutil.py
+++ b/mercurial/destutil.py
@@ -13,7 +13,7 @@ from . import (
 error,
 obsutil,
 scmutil,
-stack
+stack as stackmod,
 )
 
 def orphanpossibledestination(repo, rev):
@@ -378,7 +378,7 @@ def desthistedit(ui, repo):
 default = ui.config('histedit', 'defaultrev')
 
 if default is None:
-revs = stack.getstack(repo)
+revs = stackmod.stack(repo).revs
 elif default:
 revs = scmutil.revrange(repo, [default])
 else:
@@ -391,7 +391,7 @@ def desthistedit(ui, repo):
 return None
 
 def stackbase(ui, repo):
-revs = stack.getstack(repo)
+revs = stackmod.stack(repo).revs
 return revs.first() if revs else None
 
 def _statusotherbook(ui, repo):
diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -1695,12 +1695,11 @@ def stack(repo, subset, x):
 parent. (EXPERIMENTAL)
 """
 if x is None:
-stacks = stackmod.getstack(repo)
+stacks = stackmod.stack(repo).revs
 else:
 stacks = smartset.baseset([])
 for revision in getset(repo, fullreposet(repo), x):
-currentstack = stackmod.getstack(repo, revision)
-stacks = stacks + currentstack
+stacks += stackmod.stack(repo, revision).revs
 
 return subset & stacks
 
diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -7,17 +7,27 @@
 
 from __future__ import absolute_import
 
-def getstack(repo, rev=None):
-"""return a sorted smartrev of the stack containing either rev if it is
-not None or the current working directory parent.
+class stack(object):
+"""Collection of revisions grouped into a stack.
 
-The stack will always contain all drafts changesets which are ancestors to
-the revision and are not merges.
+The stack usually contains all drafts changesets which are ancestors to
+the given revision and are not merges, but extensions are allowed to modify
+stack definition (and add new methods to this class).
 """
-if rev is None:
-rev = '.'
+def __init__(self, repo, rev=None):
+"""Stack object contatining either rev (if it is not None) or the
+current working directory parent.
+"""
+self._repo = repo
+
+if rev is None:
+rev = '.'
 
-revspec = 'only(%s) and not public() and not ::merge()'
-revisions = repo.revs(revspec, rev)
-revisions.sort()
-return revisions
+revspec = 'only(%s) and not public() and not ::merge()'
+self.revs = self._repo.revs(revspec, rev)
+self.revs.sort()
+
+def __nonzero__(self):
+return bool(self.revs)
+
+__bool__ = __nonzero__
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2 V2] stack: add indexedrevs property to contain a list of stack revs and its base

2019-09-25 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1569139071 -25200
#  Sun Sep 22 14:57:51 2019 +0700
# Node ID b85dea9c83a01ae6c6045b7dc5e4aa10dfbec8c7
# Parent  2c9d35029c27f3d0e63afc8f618268f079f337c3
# EXP-Topic stack-object
stack: add indexedrevs property to contain a list of stack revs and its base

Sometimes we need to access a specific stack revision by its index, but
stack.revs doesn't support indexing. Obviously we can just do list(st.revs),
but it's more convenient to have a property specifically for this task.

indexedrevs also contains stack base at index 0, so actual stack revisions
start from index 1.

diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -31,3 +31,11 @@ class stack(object):
 return bool(self.revs)
 
 __bool__ = __nonzero__
+
+@property
+def indexedrevs(self):
+if self.revs:
+base = self._repo[self.revs.first()].p1()
+else:
+base = self._repo['.']
+return [base.rev()] + list(self.revs)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH STABLE] merge: back out changeset a4ca0610c754 (parents order when grafting a merge)

2019-09-22 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1568997063 -25200
#  Fri Sep 20 23:31:03 2019 +0700
# Branch stable
# Node ID 6003cc13f906fac5b6d93c5eff727e772d3dfc6a
# Parent  085295f828459f8ce90f6f5889bac3e0405945a8
merge: back out changeset a4ca0610c754 (parents order when grafting a merge)

Turns out it's not enough to just swap parents, because when we do, there are
unexpected bad side effects, such as a tracked file becoming untracked. These
side effects need more code to be handled properly, but it's not written yet.
Let's back this feature out from stable for now and some day implement it on
default instead.

diff --git a/mercurial/merge.py b/mercurial/merge.py
--- a/mercurial/merge.py
+++ b/mercurial/merge.py
@@ -2249,23 +2249,17 @@ def graft(repo, ctx, pctx, labels=None, 
mergeancestor=mergeancestor, labels=labels)
 
 
-potherp1 = False
 if keepconflictparent and stats.unresolvedcount:
 pother = ctx.node()
 else:
 pother = nullid
 parents = ctx.parents()
 if keepparent and len(parents) == 2 and pctx in parents:
-if pctx == parents[1]:
-potherp1 = True
 parents.remove(pctx)
 pother = parents[0].node()
 
 with repo.dirstate.parentchange():
-if potherp1:
-repo.setparents(pother, repo['.'].node())
-else:
-repo.setparents(repo['.'].node(), pother)
+repo.setparents(repo['.'].node(), pother)
 repo.dirstate.write(repo.currenttransaction())
 # fix up dirstate for copies and renames
 copies.duplicatecopies(repo, repo[None], ctx.rev(), pctx.rev())
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 4 of 4] revset: introduce a 'foo#stack[n]' subscript relation to access stack revisions

2019-09-22 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1569139969 -25200
#  Sun Sep 22 15:12:49 2019 +0700
# Node ID ab8f097abacb8ce0f9cea2bce0924bb2fd3261a2
# Parent  07af98a1e730c1ffa6911c9ab2cdcc06d4ffe52d
# EXP-Topic stack-object
revset: introduce a 'foo#stack[n]' subscript relation to access stack revisions

The idea behind making n = 0 cases special is that stack base should be
accessible, but only when users ask for it explicitly.

diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -284,6 +284,43 @@ def generationsrel(repo, subset, x, rel,
 
 return subset & s
 
+def stackrel(repo, subset, x, rel, z, order):
+a, b = getintrange(z,
+   _('relation subscript must be an integer or a range'),
+   _('relation subscript bounds must be integers'),
+   deffirst=None,
+   deflast=None)
+
+s = getset(repo, fullreposet(repo), x)
+if not s:
+return baseset()
+
+def getrange(st, a, b):
+start = 1 if a is None else a
+end = len(st.indexedrevs) if b is None else b + 1
+return range(start, end)
+
+revs = []
+for r in s:
+st = stackmod.stack(repo, rev=r)
+for n in getrange(st, a, b):
+if abs(n) >= len(st.indexedrevs):
+# also means stack base is not accessible with n < 0, which
+# is by design
+continue
+if n == 0 and b != 0 and a != 0:
+# quirk: we don't want stack base unless specifically asked
+# for it (at least one of the indices is 0)
+continue
+rev = st.indexedrevs[n]
+if rev == node.nullrev and n == 0:
+# we also don't want stack base if it's nullrev
+continue
+if rev not in revs:
+revs.append(rev)
+
+return subset & baseset(revs)
+
 def relsubscriptset(repo, subset, x, y, z, order):
 # this is pretty basic implementation of 'x#y[z]' operator, still
 # experimental so undocumented. see the wiki for further ideas.
@@ -2345,6 +2382,8 @@ methods = {
 subscriptrelations = {
 "g": generationsrel,
 "generations": generationsrel,
+"s": stackrel,
+"stack": stackrel,
 }
 
 def lookupfn(repo):
diff --git a/tests/test-stack.t b/tests/test-stack.t
--- a/tests/test-stack.t
+++ b/tests/test-stack.t
@@ -69,7 +69,7 @@ Check that stack doesn't include public 
 Simple test
 ---
 
-'stack()' list all changeset in the branch
+'stack()' revset lists all changeset in the branch
 
   $ hg branch
   foo
@@ -84,6 +84,48 @@ Simple test
   |
   ~
 
+'#stack[]' (as well as '#s[]') revset relation works
+
+  $ hg log -r 'foo#stack[0]'
+  1 other public c_b
+  $ hg log -r 'foo#stack[1]'
+  2 foo draft c_c
+  $ hg log -r 'foo#stack[2]'
+  3 foo draft c_d
+  $ hg log -r 'foo#stack[-1]'
+  5 foo draft c_f
+  $ hg log -r 'foo#stack[-2]'
+  4 foo draft c_e
+
+  $ hg log -r 'foo#s[0:0]'
+  1 other public c_b
+  $ hg log -r 'foo#s[:]'
+  2 foo draft c_c
+  3 foo draft c_d
+  4 foo draft c_e
+  5 foo draft c_f
+  $ hg log -r 'foo#s[:3]'
+  2 foo draft c_c
+  3 foo draft c_d
+  4 foo draft c_e
+  $ hg log -r 'foo#s[3:]'
+  4 foo draft c_e
+  5 foo draft c_f
+  $ hg log -r 'foo#s[0:1]'
+  1 other public c_b
+  2 foo draft c_c
+  $ hg log -r 'foo#s[-1:0]'
+  1 other public c_b
+  5 foo draft c_f
+  $ hg log -r 'foo#s[-4:4]'
+  2 foo draft c_c
+  3 foo draft c_d
+  4 foo draft c_e
+  5 foo draft c_f
+
+  $ hg log -r 'all()#s[]'
+  $ hg log -r 'all()#s[-]'
+
 Case with some of the branch unstable
 
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 4] stack: take getstack() and turn it into stack class (API)

2019-09-22 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1569138369 -25200
#  Sun Sep 22 14:46:09 2019 +0700
# Node ID 6430e0ae6d86343980578e36fa26c5e4893170fd
# Parent  d81e537a421f78d9f1bf6b3bdf736977ad126f68
# EXP-Topic stack-object
stack: take getstack() and turn it into stack class (API)

Stack used to be just a set of revisions, but it's going to grow more features
and it makes sense to encapsulate them into an object.

One reason we don't make stack class inherit from something like smartset class
(and be an iterable containing stack revisions) is that there's going to be
another property related to revisions and we don't want any ambiguity.

diff --git a/mercurial/destutil.py b/mercurial/destutil.py
--- a/mercurial/destutil.py
+++ b/mercurial/destutil.py
@@ -13,7 +13,7 @@ from . import (
 error,
 obsutil,
 scmutil,
-stack
+stack as stackmod,
 )
 
 def orphanpossibledestination(repo, rev):
@@ -378,7 +378,7 @@ def desthistedit(ui, repo):
 default = ui.config('histedit', 'defaultrev')
 
 if default is None:
-revs = stack.getstack(repo)
+revs = stackmod.stack(repo).revs
 elif default:
 revs = scmutil.revrange(repo, [default])
 else:
@@ -391,7 +391,7 @@ def desthistedit(ui, repo):
 return None
 
 def stackbase(ui, repo):
-revs = stack.getstack(repo)
+revs = stackmod.stack(repo).revs
 return revs.first() if revs else None
 
 def _statusotherbook(ui, repo):
diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -1695,12 +1695,11 @@ def stack(repo, subset, x):
 parent. (EXPERIMENTAL)
 """
 if x is None:
-stacks = stackmod.getstack(repo)
+stacks = stackmod.stack(repo).revs
 else:
 stacks = smartset.baseset([])
 for revision in getset(repo, fullreposet(repo), x):
-currentstack = stackmod.getstack(repo, revision)
-stacks = stacks + currentstack
+stacks += stackmod.stack(repo, revision).revs
 
 return subset & stacks
 
diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -10,17 +10,27 @@ from __future__ import absolute_import
 from . import (
 )
 
-def getstack(repo, rev=None):
-"""return a sorted smartrev of the stack containing either rev if it is
-not None or the current working directory parent.
+class stack(object):
+"""Collection of revisions grouped into a stack.
 
-The stack will always contain all drafts changesets which are ancestors to
-the revision and are not merges.
+The stack usually contains all drafts changesets which are ancestors to
+the given revision and are not merges, but extensions are allowed to modify
+stack definition (and add new methods to this class).
 """
-if rev is None:
-rev = '.'
+def __init__(self, repo, rev=None):
+"""Stack object contatining either rev (if it is not None) or the
+current working directory parent.
+"""
+self._repo = repo
+
+if rev is None:
+rev = '.'
 
-revspec = 'only(%s) and not public() and not ::merge()'
-revisions = repo.revs(revspec, rev)
-revisions.sort()
-return revisions
+revspec = 'only(%s) and not public() and not ::merge()'
+self.revs = self._repo.revs(revspec, rev)
+self.revs.sort()
+
+def __nonzero__(self):
+return bool(self.revs)
+
+__bool__ = __nonzero__
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 4] stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange()

2019-09-22 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1569137636 -25200
#  Sun Sep 22 14:33:56 2019 +0700
# Node ID d81e537a421f78d9f1bf6b3bdf736977ad126f68
# Parent  44be33cf7a5720f681fe902c83d8cc4aa1c26127
# EXP-Topic stack-object
stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange()

Using scmutil.revrange() it's possible to use multiple revsets at the same
time, but we're not using that functionality in stack.

I thought maybe that function could be used to make stack definition
customizable (by combining various parts into one set), but scmutil.revrange()
gives the union of all provided revsets, which is not very useful in stack's
case (we want "and" between parts, not "or").

diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -8,8 +8,6 @@
 from __future__ import absolute_import
 
 from . import (
-revsetlang,
-scmutil,
 )
 
 def getstack(repo, rev=None):
@@ -23,7 +21,6 @@ def getstack(repo, rev=None):
 rev = '.'
 
 revspec = 'only(%s) and not public() and not ::merge()'
-revset = revsetlang.formatspec(revspec, rev)
-revisions = scmutil.revrange(repo, [revset])
+revisions = repo.revs(revspec, rev)
 revisions.sort()
 return revisions
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 3 of 4] stack: add indexedrevs property to contain a list of stack revs and its base

2019-09-22 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1569139071 -25200
#  Sun Sep 22 14:57:51 2019 +0700
# Node ID 07af98a1e730c1ffa6911c9ab2cdcc06d4ffe52d
# Parent  6430e0ae6d86343980578e36fa26c5e4893170fd
# EXP-Topic stack-object
stack: add indexedrevs property to contain a list of stack revs and its base

Sometimes we need to access a specific stack revision by its index, but
stack.revs doesn't support indexing. Obviously we can just do list(st.revs),
but it's more convenient to have a cached property specifically for this task.

indexedrevs also contains stack base at index 0, so actual stack revisions
start from index 1.

diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -8,6 +8,7 @@
 from __future__ import absolute_import
 
 from . import (
+util,
 )
 
 class stack(object):
@@ -34,3 +35,11 @@ class stack(object):
 return bool(self.revs)
 
 __bool__ = __nonzero__
+
+@util.propertycache
+def indexedrevs(self):
+if self.revs:
+base = self._repo[self.revs.first()].p1()
+else:
+base = self._repo['.']
+return [base.rev()] + list(self.revs)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH STABLE] merge: respect parents order when using `graft` on a merge, this time for real

2019-09-18 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1568803990 -25200
#  Wed Sep 18 17:53:10 2019 +0700
# Branch stable
# Node ID 085295f828459f8ce90f6f5889bac3e0405945a8
# Parent  e26c2440a030b2c5fc43de1a2feedee37d437557
merge: respect parents order when using `graft` on a merge, this time for real

See a4ca0610c754.

potherp1 is a boolean variable that means "pother is ctx.p1", and parents is
naturally [ctx.p1, ctx.p2].

pctx is always removed from parents, so if pctx is parents[0], then we end up
using parents[1] as pother. To be true to its name, potherp1 should then be
True only when pctx is at parents[1].

diff --git a/mercurial/merge.py b/mercurial/merge.py
--- a/mercurial/merge.py
+++ b/mercurial/merge.py
@@ -2256,7 +2256,7 @@ def graft(repo, ctx, pctx, labels=None, 
 pother = nullid
 parents = ctx.parents()
 if keepparent and len(parents) == 2 and pctx in parents:
-if pctx == parents[0]:
+if pctx == parents[1]:
 potherp1 = True
 parents.remove(pctx)
 pother = parents[0].node()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --registered flag to show all known configs

2019-09-17 Thread av6 (Anton Shestakov)
av6 added a comment.


  In D6709#100618 , @marmoute 
wrote:
  
  > In D6709#99199 , @av6 wrote:
  >
  >> I'm strongly -1 on adding qualifiers straight to the keys. The primary 
usage scenario here is scripts (as explained in issue6014) -- regular users 
lived without this feature for years and didn't care (enough to file a bug) 
about getting all config options, or their default values, //or// the 
experimental status (they could and still can read it in hg help config). 
`--registered` is needed for things like shell completions, and the output 
needs to be clear and parseable (and consistent with what regular showconfig 
shows).
  >
  > I disagree that the primary use is script only. As a suer I have wanted 
this for a long time and I am happy to finally have a way to get this data 
without grepping the source.
  
  Oh, now I see what you wanted from this patch. But you want it as a developer 
who works with and on hg, not just as a user (hopefully regular users don't 
have to grep the source). This distinction makes things easier to design, 
because we now have simply two (plus one) cases:
  
  - `--registered` will simply extend the list of config options to walk from 
options found somewhere in system/user/repo config files to every config option 
ever registered (excluding experimental/devel/debug ones unless `-v` is 
given//*//)
  - existing `--debug` mode of showconfig will show the `(EXPERIMENTAL)` and 
`(default: x)` information in addition to what it shows now and can be used 
with `--registered` (and registered but unset options can have "" 
source, similar to the existing "" source)
  - anyone can still use `-T` to access key, value, defaultvalue, source and 
status in whatever format they want, and `--registered` will work as expected 
from its name (i.e. just iterating over a different set of config options)
  
  //*// This is still not great, because if you set an experimental config 
option and run showconfig with no flags, it will be in the output. With 
`--registered` as it is implemented right now it won't be shown without `-v`. 
We should either show any options when they are set  regardless of what status 
they have, or not require `-v` at all.
  
  Making one flag do one thing is good UI. That's why I want `--registered` 
alone to not modify any output of showconfig. Doing only one thing is also 
easier for help text to explain and for users to understand (even without 
reading help text, just based on the name of the flag).
  
  And to make the review process easier, I propose doing this in 3 or 4 patches:
  
  - adding `--registered`: will simply show all registered options in key=value 
format
  - adding defaults and experimental/devel/debug statuses to `showconfig 
--debug` output (this one can be split into two)
  - showing config options in a human-friendly format

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6, marmoute, durin42
Cc: durin42, mharbison72, yuja, pulkit, marmoute, av6, mjpieters, 
mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH evolve-ext] docs: add example for the `prune` command

2019-09-13 Thread Anton Shestakov
This patch seems to have fallen entirely through the cracks. Try CCing
marmoute in V2.

On Fri, 19 Jul 2019 16:29:42 +0200
Raphaël Gomès  wrote:

> # HG changeset patch
> # User Raphaël Gomès 
> # Date 1563546408 -7200
> #  Fri Jul 19 16:26:48 2019 +0200
> # Branch stable
> # Node ID 7fc102507d369c4c8243eb4fc5c7fe21af96aca3
> # Parent  124cf32dd207413d1fb2cb0dcaf39d70ba7551fd
> # EXP-Topic documentation
> docs: add example for the `prune` command
> 
> Giving at least one example helps clear up the syntax, especially since most
> options will follow a very similar pattern.
> 
> diff -r 124cf32dd207 -r 7fc102507d36 hgext3rd/evolve/cmdrewrite.py
> --- a/hgext3rd/evolve/cmdrewrite.py   Fri Jul 19 17:40:45 2019 +0800
> +++ b/hgext3rd/evolve/cmdrewrite.py   Fri Jul 19 16:26:48 2019 +0200
> @@ -998,6 +998,10 @@
>  ``--pair`` option to pair the pruned precursor and successor changesets.
>  This is commonly useful for resolving history divergence, or when someone
>  else does edits history without obsolescence enabled.
> +
> +``hg prune A::B -s C::D --pair`` will mark all revisions in the A::B 
> range
> +as superseded by the revisions in C::D. Both revsets need to have the 
> same
> +number of changesets.

I think this should be put under `.. container:: verbose` (see core
mercurial/commands.py). Usually, command examples are only visible in hg
help output when --verbose is used, that helps keeping help text short.

Otherwise LGTM.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --registered flag to show all known configs

2019-09-12 Thread av6 (Anton Shestakov)
av6 added a comment.


  I'll be okay with this too, once we get rid of `(EXPERIMENTAL)` everywhere.

INLINE COMMENTS

> test-config.t:962
> +
> +  $ hg showconfig --registered -T '{name}={value}\n' | egrep '^(color|diff)'
> +  color.mode=auto

Let's change this to `hg showconfig cmdserver --registered --verbose -T 
'{name}={value}\n'`, no grep. cmdserver section has a variety of options, 
including experimental ones, plus that would test showing config sections by 
name with --registered.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6, marmoute, durin42
Cc: durin42, mharbison72, yuja, pulkit, marmoute, av6, mjpieters, 
mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6762: packaging: add Bullseye, remove Jessie

2019-08-25 Thread av6 (Anton Shestakov)
Closed by commit rHG0a50a4232db7: packaging: add Bullseye, remove Jessie 
(authored by av6).
This revision was automatically updated to reflect the committed changes.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D6762?vs=16308=16310

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6762/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6762

AFFECTED FILES
  contrib/packaging/Makefile

CHANGE DETAILS

diff --git a/contrib/packaging/Makefile b/contrib/packaging/Makefile
--- a/contrib/packaging/Makefile
+++ b/contrib/packaging/Makefile
@@ -1,9 +1,9 @@
 $(eval HGROOT := $(shell cd ../..; pwd))
 
 DEBIAN_CODENAMES := \
-  jessie \
   stretch \
-  buster
+  buster \
+  bullseye
 
 UBUNTU_CODENAMES := \
   xenial \



To: av6, #hg-reviewers, indygreg
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6761: packaging: add Cosmic and Disco, remove Trusty and Artful

2019-08-25 Thread av6 (Anton Shestakov)
Closed by commit rHG0363bb086c57: packaging: add Cosmic and Disco, remove 
Trusty and Artful (authored by av6).
This revision was automatically updated to reflect the committed changes.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D6761?vs=16307=16309

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6761/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6761

AFFECTED FILES
  contrib/packaging/Makefile

CHANGE DETAILS

diff --git a/contrib/packaging/Makefile b/contrib/packaging/Makefile
--- a/contrib/packaging/Makefile
+++ b/contrib/packaging/Makefile
@@ -6,10 +6,10 @@
   buster
 
 UBUNTU_CODENAMES := \
-  trusty \
   xenial \
-  artful \
   bionic \
+  cosmic \
+  disco
 
 FEDORA_RELEASES := \
   20 \



To: av6, #hg-reviewers, indygreg
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6761: packaging: add Cosmic and Disco, remove Trusty and Artful

2019-08-25 Thread av6 (Anton Shestakov)
av6 added a comment.


  Intended for stable.
  
  Confirming that building the packages for Cosmic and Disco actually works is 
very much welcome.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6761/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6761

To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6762: packaging: add Bullseye, remove Jessie

2019-08-25 Thread av6 (Anton Shestakov)
av6 added a comment.


  Intended for stable.
  
  Confirming that building the package for Bullseye actually works is very much 
welcome.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6762/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6762

To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6762: packaging: add Bullseye, remove Jessie

2019-08-25 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  Jessie is oldoldstable now, and Bullseye is going to be the next stable (now
  testing). We're continuing to support the current oldstable, stable and 
testing
  releases.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6762

AFFECTED FILES
  contrib/packaging/Makefile

CHANGE DETAILS

diff --git a/contrib/packaging/Makefile b/contrib/packaging/Makefile
--- a/contrib/packaging/Makefile
+++ b/contrib/packaging/Makefile
@@ -1,9 +1,9 @@
 $(eval HGROOT := $(shell cd ../..; pwd))
 
 DEBIAN_CODENAMES := \
-  jessie \
   stretch \
-  buster
+  buster \
+  bullseye
 
 UBUNTU_CODENAMES := \
   xenial \



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6761: packaging: add Cosmic and Disco, remove Trusty and Artful

2019-08-25 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  - Trusty was publicly supported until 2019-04-30
  - Artful was publicly supported until 2018-07-19
  - Cosmic was publicly supported until 2019-07-18
  - Disco will be publicly supported until 2020-01
  
  Cosmic is officially out-of-date, but since it still may be in use, and 
because
  we didn't add it when it first came out, I think it would be nice to support 
it
  until the next time somebody decides to update this list of Ubuntu releases.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6761

AFFECTED FILES
  contrib/packaging/Makefile

CHANGE DETAILS

diff --git a/contrib/packaging/Makefile b/contrib/packaging/Makefile
--- a/contrib/packaging/Makefile
+++ b/contrib/packaging/Makefile
@@ -6,10 +6,10 @@
   buster
 
 UBUNTU_CODENAMES := \
-  trusty \
   xenial \
-  artful \
   bionic \
+  cosmic \
+  disco
 
 FEDORA_RELEASES := \
   20 \



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --registered flag to show all known configs

2019-08-23 Thread av6 (Anton Shestakov)
This revision now requires changes to proceed.
av6 added a comment.
av6 requested changes to this revision.


  I'm strongly -1 on adding qualifiers straight to the keys. The primary usage 
scenario here is scripts (as explained in issue6014) -- regular users lived 
without this feature for years and didn't care (enough to file a bug) about 
getting all config options, or their default values, //or// the experimental 
status (they could and still can read it in hg help config). `--registered` is 
needed for things like shell completions, and the output needs to be clear and 
parseable (and consistent with what regular showconfig shows).
  
  Even adding "(default: x)" to values already complicates the parsing process 
to get multiple config options in a script. Yeah, a script can get individual 
values one by one, but it can take ages because of the start-up time (again, 
this is important for interactive scripts like shell completions).
  
  Let's add a test to this patch that demonstrates that scripts can //easily// 
use this new functionality. Something like `$ hg showconfig --registered -T 
'{name}={value}\n' | egrep '^(color|diff)'`. Notice how this uses -T, which is 
recommended, but people writing scripts in the wild may not even use, and extra 
things in the output (i.e. anything other than just key and value) will trip 
their scripts up. Maaaybe if we put a strongly worded note in hg help 
showconfig about scripting and usage of -T, maybe then adding "(EXPERIMENTAL)" 
would make sense. But I think the current format of adding it to the key is 
weird and it would be better to add it to the end of the line, similar to what 
experimental CLI flags have in the output of `hg help -v command` (if at all, 
because, again, that is not how regular showconfig behaves and we do have both 
defaults and experimental statuses in hg help config).
  
  Sorry for coming up with this new condition only now, but I thought everyone 
was already on the same page.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6, marmoute, durin42
Cc: durin42, mharbison72, yuja, pulkit, marmoute, av6, mjpieters, 
mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --registered flag to show all known configs

2019-08-22 Thread av6 (Anton Shestakov)
av6 added a comment.
av6 accepted this revision.


  @marmoute did you want this flag marked as experimental or am I 
misremembering?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6, marmoute, durin42
Cc: durin42, mharbison72, yuja, pulkit, marmoute, av6, mjpieters, 
mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] makefile: run Rust tests if cargo is installed

2019-08-21 Thread Anton Shestakov
On Wed, 21 Aug 2019 18:09:33 +0200
Raphaël Gomès  wrote:

> # HG changeset patch
> # User Raphaël Gomès 
> # Date 1566403010 -7200
> #  Wed Aug 21 17:56:50 2019 +0200
> # Branch stable
> # Node ID 5b9efc6098154fb5079f06b3c485b58363e0f43d
> # Parent  302dbc9d52beeb2ef677aa18b3fa005bbce2134e
> makefile: run Rust tests if cargo is installed
> 
> While no particular minimum toolchain version is targeted as of yet, this
> serves as a first step to make more people/machines run the Rust tests.
> 
> diff -r 302dbc9d52be -r 5b9efc609815 Makefile
> --- a/MakefileFri Aug 16 15:41:53 2019 +0300
> +++ b/MakefileWed Aug 21 17:56:50 2019 +0200
> @@ -110,8 +110,11 @@
>  check: tests
>  
>  tests:
> - cd tests && $(PYTHON) run-tests.py $(TESTFLAGS)
> -
> + if [ -x "$$(command -v cargo)" ]; then \
> + # Run Rust tests if cargo is installed
> + cd $(HGROOT)/rust/hg-cpython && cargo test --quiet --all; \
> + fi;
> + cd tests && $(PYTHON) run-tests.py $(TESTFLAGS) && \
>  test-%:

I most likely forgot all the intricacies of make syntax, but this looks
like a shell command is getting chained by && with a make target?

Also an unrelated change removes an empty line between "tests" and
"test-%" targets.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --registered flag to show all known configs

2019-08-20 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> commands.py:1893
>  else:
> -fm.write('name value', '%s=%s\n', entryname, value)
> -fm.data(defaultvalue=defaultvalue)
> +value_ = value
> +for tfopt in [('True', 'yes'), ('False', 'no'), ('true', 'yes'),

Let's rename this variable to better reflect its intent. AFAIU, a better name 
would be `rawvalue` or `origvalue`.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6, marmoute, durin42
Cc: durin42, mharbison72, yuja, pulkit, marmoute, av6, mjpieters, 
mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6730: config: handle default values of type list

2019-08-17 Thread av6 (Anton Shestakov)
This revision now requires changes to proceed.
av6 added a comment.
av6 requested changes to this revision.


  The changes in tests that this patch causes are actually already present in 
the D6709 , so let's fold this patch into 
it as well.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6730/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6730

To: navaneeth.suresh, #hg-reviewers, av6
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --registered flag to show all known configs

2019-08-17 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> ui.py:832
> +# Omit config items with dynamicdefault, devel,
> +# experimental and generic config opts.
> +continue

Nit: originally I was fine with two different `if ...: continue` blocks here, 
and I still think it would be better. Not only the condition here is fairly 
complex and spans multiple lines (so not easy to read), but this comment is not 
quite correct. We always omit items with dynamic defaults and generic items, 
but experimental (& etc) items are only omitted unless --verbose is given. Two 
comments in two if-blocks with two separate conditions here would be more 
readable.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6, marmoute, durin42
Cc: durin42, mharbison72, yuja, pulkit, marmoute, av6, mjpieters, 
mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6707: revset: drop argument when it's None

2019-08-06 Thread av6 (Anton Shestakov)
Closed by commit rHG911e25dc9d8c: revset: drop argument when its None 
(authored by av6).
This revision was automatically updated to reflect the committed changes.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D6707?vs=16107=16139

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6707/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6707

AFFECTED FILES
  mercurial/revset.py

CHANGE DETAILS

diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -1695,7 +1695,7 @@
 parent. (EXPERIMENTAL)
 """
 if x is None:
-stacks = stackmod.getstack(repo, x)
+stacks = stackmod.getstack(repo)
 else:
 stacks = smartset.baseset([])
 for revision in getset(repo, fullreposet(repo), x):



To: av6, #hg-reviewers, pulkit
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6706: stack: remove unnecessary reverse() predicate

2019-08-06 Thread av6 (Anton Shestakov)
Closed by commit rHG77c52ce50e6a: stack: remove unnecessary reverse() predicate 
(authored by av6).
This revision was automatically updated to reflect the committed changes.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D6706?vs=16106=16138

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6706/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6706

AFFECTED FILES
  mercurial/stack.py

CHANGE DETAILS

diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -22,7 +22,7 @@
 if rev is None:
 rev = '.'
 
-revspec = 'reverse(only(%s) and not public() and not ::merge())'
+revspec = 'only(%s) and not public() and not ::merge()'
 revset = revsetlang.formatspec(revspec, rev)
 revisions = scmutil.revrange(repo, [revset])
 revisions.sort()



To: av6, #hg-reviewers, pulkit
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6709: config: add --all flag to show all known configs

2019-08-02 Thread av6 (Anton Shestakov)
This revision now requires changes to proceed.
av6 added inline comments.
av6 requested changes to this revision.

INLINE COMMENTS

> commands.py:1774
>  @command('config|showconfig|debugconfig',
> -[('u', 'untrusted', None, _('show untrusted configuration options')),
> +[('a', 'all', None, _('show all known configuration options')),
> + ('u', 'untrusted', None, _('show untrusted configuration options')),

This needs a better description to differentiate this flag and the default mode 
(see line 1786).

> test-config.t:238
> +  progress.format=['topic', 'bar', 'number', 'estimate']
> +  devel-warn: config item requires an explicit default value: 
> 'progress.width' at: 
> /tmp/hgtests.Ps_zAY/install/lib/python/mercurial/commands.py:1876 (config)
> +  progress.width=None

Certainly a good way to find all config options without default values, but in 
the final implementation of `showconfig -a` it should not produce any warnings 
(especially not developer warnings).

It's probably possible to add default values to some of the items this test 
found, but I think some of them are missing defaults by design (an obvious 
example being `alias..*`). In that case it might be better to just skip them.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6709/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6709

To: navaneeth.suresh, #hg-reviewers, av6
Cc: av6, mjpieters, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6707: revset: drop argument when it's None

2019-08-02 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  getstack's definition is `getstack(repo, rev=None)`, so providing None
  explicitly is unnecessary. Moreover, when x is not None, it's definitely not a
  revision but a part of a parsed tree of revset arguments.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6707

AFFECTED FILES
  mercurial/revset.py

CHANGE DETAILS

diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -1695,7 +1695,7 @@
 parent. (EXPERIMENTAL)
 """
 if x is None:
-stacks = stackmod.getstack(repo, x)
+stacks = stackmod.getstack(repo)
 else:
 stacks = smartset.baseset([])
 for revision in getset(repo, fullreposet(repo), x):



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6706: stack: remove unnecessary reverse() predicate

2019-08-02 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  Stack already sorts revisions, so no need to do it twice.
  
  This change was a part of D2400 , which 
didn't land for other reasons. See also
  D2399 , where this change was suggested.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6706

AFFECTED FILES
  mercurial/stack.py

CHANGE DETAILS

diff --git a/mercurial/stack.py b/mercurial/stack.py
--- a/mercurial/stack.py
+++ b/mercurial/stack.py
@@ -22,7 +22,7 @@
 if rev is None:
 rev = '.'
 
-revspec = 'reverse(only(%s) and not public() and not ::merge())'
+revspec = 'only(%s) and not public() and not ::merge()'
 revset = revsetlang.formatspec(revspec, rev)
 revisions = scmutil.revrange(repo, [revset])
 revisions.sort()



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH evolve-ext] evolve: further clarify that update is performed only when requested

2019-07-18 Thread Anton Shestakov
On Wed, 17 Jul 2019 12:06:14 -0700
Kevin Peng via Mercurial-devel 
wrote:

> Here is an updated patch:
> 
> # HG changeset patch
> # User kevp...@google.com
> # Date 1560563083 25200
> #  Fri Jun 14 18:44:43 2019 -0700
> # Node ID 8716e0b2ff1cf09efa79dca6303a83600ee42824
> # Parent  8195452be71d446eff972ea128199f943731b7fb
> evolve: further clarify when update is performed
> 
> diff --git a/hgext3rd/evolve/evolvecmd.py b/hgext3rd/evolve/evolvecmd.py
> --- a/hgext3rd/evolve/evolvecmd.py
> +++ b/hgext3rd/evolve/evolvecmd.py
> @@ -1536,9 +1536,9 @@ def evolve(ui, repo, **opts):
>  If so, evolve rebases that changeset. If not, evolve refuses to guess 
> your
>  intention, and gives a hint about what you might want to do next.
> 
> -Any time evolve creates a changeset, it updates the working copy to the 
> new
> -changeset. Using ``--update`` will make evolve perform an update after 
> any
> -successful evolve operation.
> +When ``--update`` is set, a successful evolve operation will update the
> +working copy to the newly created changeset. Moreover, an update will
> +always be performed if the current working directory parent is obsolete.
> 
>  Automatic mode only handles common use cases. For example, it avoids 
> taking
>  action in the case of ambiguity, and it ignores orphan changesets that 
> are

We already pushed your previous patch after some copy editing, so I
took the liberty of amending this one to apply it cleanly. It can be
seen and reviewed (if you have bitbucket account) at:
https://bitbucket.org/octobus/evolve-devel/commits/d0965c5c5335d14ea0bcb4e0bf336f43ba4fe381

And it looks good to me.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6551: statecheck: added support for cmdutil.afterresolvedstates

2019-07-04 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> cmdutil.py:3303
>  
>  afterresolvedstates tuples define a .hg/{file} and the corresponding
>  command needed to finish it.

Now that afterresolvedstates has been removed, you need to update this 
docstring.

> cmdutil.py:3322
>  
>  If there's a matching afterresolvedstates, howtocontinue will yield
>  repo.ui.warn as the reporter.

Here too.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6551/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6551

To: taapas1128, durin42, martinvonz, #hg-reviewers
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2] move: --force flag forcibly moves, not copies

2019-07-02 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1562119599 -28800
#  Wed Jul 03 10:06:39 2019 +0800
# Node ID 47ba6b2b35db31c4b436e9e99179607cc4cc86cc
# Parent  9151cf680e05ebe7322388f25af3376f52e004a8
move: --force flag forcibly moves, not copies

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -4759,7 +4759,7 @@ def remove(ui, repo, *pats, **opts):
 
 @command('rename|move|mv',
 [('A', 'after', None, _('record a rename that has already occurred')),
-('f', 'force', None, _('forcibly copy over an existing managed file')),
+('f', 'force', None, _('forcibly move over an existing managed file')),
 ] + walkopts + dryrunopts,
 _('[OPTION]... SOURCE... DEST'),
 helpcategory=command.CATEGORY_WORKING_DIRECTORY)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2] copy: correct synopsis by making SOURCE a required argument

2019-07-02 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1562119311 -28800
#  Wed Jul 03 10:01:51 2019 +0800
# Node ID 9151cf680e05ebe7322388f25af3376f52e004a8
# Parent  e3df1e15bee9d70d6cc4697e503091a7bff0f8fc
copy: correct synopsis by making SOURCE a required argument

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -1873,7 +1873,7 @@ def config(ui, repo, *values, **opts):
 [('A', 'after', None, _('record a copy that has already occurred')),
 ('f', 'force', None, _('forcibly copy over an existing managed file')),
 ] + walkopts + dryrunopts,
-_('[OPTION]... [SOURCE]... DEST'),
+_('[OPTION]... SOURCE... DEST'),
 helpcategory=command.CATEGORY_FILE_CONTENTS)
 def copy(ui, repo, *pats, **opts):
 """mark files as copied for the next commit
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH evolve-ext] py3: broad pass for python3 compatibility

2019-06-27 Thread Anton Shestakov
On Wed, 26 Jun 2019 15:55:50 -0700
"Ludovic Chabant"  wrote:

> Should I re-create the patch on the latest evolve stable now? Or will someone 
> else do it? 
> I'm asking because py3 support is blocking a few things for sourcehut.
> Thanks!

Personally, I thought you all would discuss py3 efforts and testing
plan for evolve on the conference in Paris. Not sure if any of that took
place, but if not, you need to, indeed, redo this patch and then nag
Pierre-Yves to queue it and set up evolve-py3 on octobus-ci jenkins,
preferably all at the same time.

We definitely want this patch, but we equally want a way to test (not
just locally) that it keeps working. Maybe we can better coordinate the
efforts in #hg-evolve.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH evolve-ext] evolve: further clarify that update is performed only when requested

2019-06-24 Thread Anton Shestakov
On Fri, 14 Jun 2019 21:20:39 -0700
kevpeng--- via Mercurial-devel 
wrote:

> # HG changeset patch
> # User kevp...@google.com
> # Date 1560563083 25200
> #  Fri Jun 14 18:44:43 2019 -0700
> # Node ID 26769b7cb539e08ed51823750fe799cef1f10bf5
> # Parent  8195452be71d446eff972ea128199f943731b7fb
> evolve: further clarify that update is performed only when requested

To be precise, evolve still performs an update when working directory
parent is obsolete (no need for --update); and _warnobsoletewc() in
evolve/__init__.py recommends running plain `hg evolve` in such case.

I'll ping Pierre-Yves about this patch, sorry about the delay.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6501: state: created new class statecheck to handle unfinishedstates

2019-06-18 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> state.py:151
> +'graft',
> +fname = 'graftstate',
> +clearable = True,

It's funny how Pulkit's comment is now at this line and looks like asking to 
add spaces around `=` here. But in this case `=` is not an operator, it's used 
to indicate keyword arguments. We don't want spaces around it (similarly to 
PEP8).

Bad:

  addunfinished(
  'graft',
  fname = 'graftstate',
  clearable = True,
  allowcommit = False,
  cmdhint = _("use 'hg graft --continue' or 'hg graft --stop' to stop")
  )

Good:

  addunfinished(
  'graft',
  fname='graftstate',
  clearable=True,
  allowcommit=False,
  cmdhint=_("use 'hg graft --continue' or 'hg graft --stop' to stop")
  )

Even better (as long as it fits into 79 characters per line):

  addunfinished(
  'graft', 'graftstate', clearable=True, allowcommit=False,
  cmdhint=_("use 'hg graft --continue' or 'hg graft --stop' to stop")
  )

There's a lot of places where this needs to be fixed in this series, not just 
here.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D6501/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D6501

To: taapas1128, durin42, martinvonz, #hg-reviewers
Cc: av6, Kwan, pulkit, mjpieters, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6476: merge: correct argument name in docstring

2019-06-04 Thread av6 (Anton Shestakov)
This revision was automatically updated to reflect the committed changes.
Closed by commit rHG127937874395: merge: correct argument name in docstring 
(authored by av6, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D6476?vs=15332=15333

REVISION DETAIL
  https://phab.mercurial-scm.org/D6476

AFFECTED FILES
  mercurial/merge.py

CHANGE DETAILS

diff --git a/mercurial/merge.py b/mercurial/merge.py
--- a/mercurial/merge.py
+++ b/mercurial/merge.py
@@ -2202,7 +2202,7 @@
 pctx - merge base, usually ctx.p1()
 labels - merge labels eg ['local', 'graft']
 keepparent - keep second parent if any
-keepparent - if unresolved, keep parent used for the merge
+keepconflictparent - if unresolved, keep parent used for the merge
 
 """
 # If we're grafting a descendant onto an ancestor, be sure to pass



To: av6, #hg-reviewers, pulkit
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6476: merge: correct argument name in docstring

2019-06-04 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6476

AFFECTED FILES
  mercurial/merge.py

CHANGE DETAILS

diff --git a/mercurial/merge.py b/mercurial/merge.py
--- a/mercurial/merge.py
+++ b/mercurial/merge.py
@@ -2202,7 +2202,7 @@
 pctx - merge base, usually ctx.p1()
 labels - merge labels eg ['local', 'graft']
 keepparent - keep second parent if any
-keepparent - if unresolved, keep parent used for the merge
+keepconflictparent - if unresolved, keep parent used for the merge
 
 """
 # If we're grafting a descendant onto an ancestor, be sure to pass



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6467: doc: fix description of "predecessors" to match reality

2019-06-01 Thread av6 (Anton Shestakov)
av6 added a comment.


  This change looks good, but I have doubts about "visible" in the docstring. 
https://phab.mercurial-scm.org/rHG1858fc2327ef7b631941e37550738f1fc4217bfb does 
say that this template keyword respects repo filtering, but I've encountered 
instances where it shows hidden predecessors (that need --hidden to be seen).

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6467

To: joerg.sonnenberger, #hg-reviewers
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6461: githelp: translate git stash show and clear actions and --patch flag

2019-05-30 Thread av6 (Anton Shestakov)
This revision was automatically updated to reflect the committed changes.
Closed by commit rHG7752cd3a2f83: githelp: translate git stash show and clear 
actions and --patch flag (authored by av6, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D6461?vs=15298=15301

REVISION DETAIL
  https://phab.mercurial-scm.org/D6461

AFFECTED FILES
  hgext/githelp.py
  tests/test-githelp.t

CHANGE DETAILS

diff --git a/tests/test-githelp.t b/tests/test-githelp.t
--- a/tests/test-githelp.t
+++ b/tests/test-githelp.t
@@ -219,6 +219,22 @@
   $ hg githelp -- git stash drop xyz
   hg shelve -d xyz
 
+githelp for stash list with patch
+  $ hg githelp -- git stash list -p
+  hg shelve -l -p
+
+githelp for stash show
+  $ hg githelp -- git stash show
+  hg shelve --stat
+
+githelp for stash show with patch and name
+  $ hg githelp -- git stash show -p mystash
+  hg shelve -p mystash
+
+githelp for stash clear
+  $ hg githelp -- git stash clear
+  hg shelve --cleanup
+
 githelp for whatchanged should show deprecated message
   $ hg githelp -- whatchanged -p
   this command has been deprecated in the git project, thus isn't supported by 
this tool
diff --git a/hgext/githelp.py b/hgext/githelp.py
--- a/hgext/githelp.py
+++ b/hgext/githelp.py
@@ -923,14 +923,26 @@
 
 def stash(ui, repo, *args, **kwargs):
 cmdoptions = [
+('p', 'patch', None, ''),
 ]
 args, opts = parseoptions(ui, cmdoptions, args)
 
 cmd = Command('shelve')
 action = args[0] if len(args) > 0 else None
 
 if action == 'list':
 cmd['-l'] = None
+if opts.get('patch'):
+cmd['-p'] = None
+elif action == 'show':
+if opts.get('patch'):
+cmd['-p'] = None
+else:
+cmd['--stat'] = None
+if len(args) > 1:
+cmd.append(args[1])
+elif action == 'clear':
+cmd['--cleanup'] = None
 elif action == 'drop':
 cmd['-d'] = None
 if len(args) > 1:
@@ -943,10 +955,9 @@
 cmd.append(args[1])
 if action == 'apply':
 cmd['--keep'] = None
-elif (action == 'branch' or action == 'show' or action == 'clear'
-or action == 'create'):
+elif action == 'branch' or action == 'create':
 ui.status(_("note: Mercurial doesn't have equivalents to the "
-"git stash branch, show, clear, or create actions\n\n"))
+"git stash branch or create actions\n\n"))
 return
 else:
 if len(args) > 0:



To: av6, #hg-reviewers, pulkit
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6461: githelp: translate git stash show and clear actions and --patch flag

2019-05-30 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6461

AFFECTED FILES
  hgext/githelp.py
  tests/test-githelp.t

CHANGE DETAILS

diff --git a/tests/test-githelp.t b/tests/test-githelp.t
--- a/tests/test-githelp.t
+++ b/tests/test-githelp.t
@@ -219,6 +219,22 @@
   $ hg githelp -- git stash drop xyz
   hg shelve -d xyz
 
+githelp for stash list with patch
+  $ hg githelp -- git stash list -p
+  hg shelve -l -p
+
+githelp for stash show
+  $ hg githelp -- git stash show
+  hg shelve --stat
+
+githelp for stash show with patch and name
+  $ hg githelp -- git stash show -p mystash
+  hg shelve -p mystash
+
+githelp for stash clear
+  $ hg githelp -- git stash clear
+  hg shelve --cleanup
+
 githelp for whatchanged should show deprecated message
   $ hg githelp -- whatchanged -p
   this command has been deprecated in the git project, thus isn't supported by 
this tool
diff --git a/hgext/githelp.py b/hgext/githelp.py
--- a/hgext/githelp.py
+++ b/hgext/githelp.py
@@ -923,14 +923,26 @@
 
 def stash(ui, repo, *args, **kwargs):
 cmdoptions = [
+('p', 'patch', None, ''),
 ]
 args, opts = parseoptions(ui, cmdoptions, args)
 
 cmd = Command('shelve')
 action = args[0] if len(args) > 0 else None
 
 if action == 'list':
 cmd['-l'] = None
+if opts.get('patch'):
+cmd['-p'] = None
+elif action == 'show':
+if opts.get('patch'):
+cmd['-p'] = None
+else:
+cmd['--stat'] = None
+if len(args) > 1:
+cmd.append(args[1])
+elif action == 'clear':
+cmd['--cleanup'] = None
 elif action == 'drop':
 cmd['-d'] = None
 if len(args) > 1:
@@ -943,10 +955,9 @@
 cmd.append(args[1])
 if action == 'apply':
 cmd['--keep'] = None
-elif (action == 'branch' or action == 'show' or action == 'clear'
-or action == 'create'):
+elif action == 'branch' or action == 'create':
 ui.status(_("note: Mercurial doesn't have equivalents to the "
-"git stash branch, show, clear, or create actions\n\n"))
+"git stash branch or create actions\n\n"))
 return
 else:
 if len(args) > 0:



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6460: githelp: add --dry-run for mv

2019-05-30 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6460

AFFECTED FILES
  hgext/githelp.py

CHANGE DETAILS

diff --git a/hgext/githelp.py b/hgext/githelp.py
--- a/hgext/githelp.py
+++ b/hgext/githelp.py
@@ -684,14 +684,17 @@
 def mv(ui, repo, *args, **kwargs):
 cmdoptions = [
 ('f', 'force', None, ''),
+('n', 'dry-run', None, ''),
 ]
 args, opts = parseoptions(ui, cmdoptions, args)
 
 cmd = Command('mv')
 cmd.extend(args)
 
 if opts.get('force'):
 cmd['-f'] = None
+if opts.get('dry_run'):
+cmd['-n'] = None
 
 ui.status((bytes(cmd)), "\n")
 



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6459: githelp: translate --directory of git apply to --prefix

2019-05-30 Thread av6 (Anton Shestakov)
av6 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  According to the help pages, these flags do the same.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6459

AFFECTED FILES
  hgext/githelp.py
  tests/test-githelp.t

CHANGE DETAILS

diff --git a/tests/test-githelp.t b/tests/test-githelp.t
--- a/tests/test-githelp.t
+++ b/tests/test-githelp.t
@@ -256,6 +256,10 @@
   $ hg githelp -- apply -p 5
   hg import --no-commit -p 5
 
+githelp for apply with prefix directory
+  $ hg githelp -- apply --directory=modules
+  hg import --no-commit --prefix modules
+
 git merge-base
   $ hg githelp -- git merge-base --is-ancestor
   ignoring unknown option --is-ancestor
diff --git a/hgext/githelp.py b/hgext/githelp.py
--- a/hgext/githelp.py
+++ b/hgext/githelp.py
@@ -192,12 +192,15 @@
 def apply(ui, repo, *args, **kwargs):
 cmdoptions = [
 ('p', 'p', int, ''),
+('', 'directory', '', ''),
 ]
 args, opts = parseoptions(ui, cmdoptions, args)
 
 cmd = Command('import --no-commit')
 if (opts.get('p')):
 cmd['-p'] = opts.get('p')
+if opts.get('directory'):
+cmd['--prefix'] = opts.get('directory')
 cmd.extend(args)
 
 ui.status((bytes(cmd)), "\n")



To: av6, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH evolve-ext] py3: broad pass for python3 compatibility

2019-05-24 Thread Anton Shestakov
On Fri, 24 May 2019 15:57:53 +
Ludovic Chabant  wrote:

> # HG changeset patch
> # User Ludovic Chabant 
> # Date 1558677189 0
> #  Fri May 24 05:53:09 2019 +
> # Node ID 3af350fa12d4dbf69d5cbbaf5ca679067472f9ee
> # Parent  0b231ea2124baf74fee5e325922a57fb0d89bbe3
> # EXP-Topic py3
> py3: broad pass for python3 compatibility
> 
> - ran mercurial's bytify-strings script
> - excluded some places where we use strings to pass to setattr()

Does this make any existing tests for evolve pass on py3?

I must say at the moment we have lots of unreviewed patches (draft in
evolve-devel), I'm hoping that they will be finally reviewed at
the oncoming post-conference sprint and then we can set up a new job in
jenkins to test evolve on py3 and start caring about the compatibility
for real. Taking other patches first would mean this patch would be
hard to apply and it would miss any newly added code, so the question
is: how hard would it be to create this patch again?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6441: help: check if a subtopic exists and raise an error if it doesn't (issue6145)

2019-05-24 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> help.py:689-695
> +exists = False
>  for names, header, doc in subtopics[name]:
>  if subtopic in names:
> +exists = True
>  break
> +if not exists:
> +raise error.UnknownCommand(name)

This made me remember that for-else statement exists.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6441

To: ngoldbaum, #hg-reviewers
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6442: help: include subtopic in error message if passed

2019-05-24 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> help.py:826
> +if subtopic:
> +hint += _(" or 'hg help --keyword %s'") % subtopic
>  raise error.Abort(msg, hint=hint)

Concatenating things is not the best option when it comes to i18n, but even if 
it were, I think it would make sense to only show here the subtopic, if it's 
provided. If people are curious about internals.foobar (or config.foobar), then 
`hg help -k foobar` helps way more than `hg help -k internals`. And we already 
make sure that the topic that comes before the dot exists, right?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6442

To: ngoldbaum, #hg-reviewers
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] histedit: make actions toggleables

2019-05-11 Thread Anton Shestakov
On Fri, 10 May 2019 10:15:31 -0700
Yu Feng  wrote:

> # HG changeset patch
> # User f...@google.com
> # Date 1557508115 25200
> #  Fri May 10 10:08:35 2019 -0700
> # Node ID 23bc04dc2d149829133db571f6a922e95843c9f9
> # Parent  458dc948aff9f1217718b7679f890fea510d54f7
> histedit: make actions toggleables.
> 
> If the same action is applied twice, revert to pick.
> 
> For example, the current state
> #0  pick   104:x   Collect progress
> 
> pressing e once
> #0  edit   104:x   Collect progress
> 
> pressing e again toggles it back to pick.
> Instead of keeping at e (behavior before this patch)
> #0  pick   104:x   Collect progress
> 
> The rationale is that giving a response when a key is pressed
> makes happy users. Toggling seems to be a reasonable response in
> this scenario.

This rationale may be good for GUI, but text-based interfaces don't
traditionally react to every possible key press. And one way to see
this patch is that it makes histedit do pretty much the opposite to what
it's told to do: I press e and it goes back to "pick". That's
surprising because action field is not a toggle, it's a choice.

Also, users don't have to change histedit plan in one go, they can
leave it waiting for input for days on end, or open another window to
see the graph and mentally think up the list of actions to mechanically
punch it in on the keyboard without looking at the current state of
histedit plan. If they know that commits A+B+C need to be edited, it
makes sense to let them press (e, down)x3 on A without making sure that
any of the actions wasn't already on "edit" because of their previous
input.

This could be a config option, that would make people knowingly opt-in
and not be surprised by the behavior.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 2 of 2] commit: add ability to print file status after each successful invocation

2019-05-03 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1556863876 -28800
#  Fri May 03 14:11:16 2019 +0800
# Node ID f95f3e733b24730f8ad5874150c2eefb9123a482
# Parent  49d7c0579df397ff05941d09ce97967e6ca9d53e
# EXP-Topic post-commit-status
commit: add ability to print file status after each successful invocation

When commands.commit.post-status is enabled, `hg commit` will effectively run
`hg status -mardu` after committing. It can help catch mistakes like not
committing all needed files or not adding unknown files that should've been
part of the just created commit.

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -1735,6 +1735,10 @@ def _docommit(ui, repo, *pats, **opts):
 
 cmdutil.commitstatus(repo, node, branch, bheads, opts)
 
+if not ui.quiet and ui.configbool('commands', 'commit.post-status'):
+status(ui, repo, modified=True, added=True, removed=True, deleted=True,
+   unknown=True, subrepos=opts.get('subrepos'))
+
 @command('config|showconfig|debugconfig',
 [('u', 'untrusted', None, _('show untrusted configuration options')),
  ('e', 'edit', None, _('edit user config')),
diff --git a/mercurial/configitems.py b/mercurial/configitems.py
--- a/mercurial/configitems.py
+++ b/mercurial/configitems.py
@@ -202,6 +202,9 @@ coreconfigitem('color', 'pagermode',
 default=dynamicdefault,
 )
 _registerdiffopts(section='commands', configprefix='commit.interactive.')
+coreconfigitem('commands', 'commit.post-status',
+default=False,
+)
 coreconfigitem('commands', 'grep.all-files',
 default=False,
 )
diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
--- a/mercurial/help/config.txt
+++ b/mercurial/help/config.txt
@@ -438,6 +438,10 @@ effect and style see :hg:`help color`.
 ``commands``
 
 
+``commit.post-status``
+Show status of files in the working directory after successful commit.
+(default: False)
+
 ``resolve.confirm``
 Confirm before performing action if no filename is passed.
 (default: False)
diff --git a/tests/test-commit.t b/tests/test-commit.t
--- a/tests/test-commit.t
+++ b/tests/test-commit.t
@@ -838,3 +838,42 @@ at the end
   second line
 
   $ cd ..
+
+testing commands.commit.post-status config option
+
+  $ hg init ci-post-st
+  $ cd ci-post-st
+  $ echo '[commands]' > .hg/hgrc
+  $ echo 'commit.post-status = 1' >> .hg/hgrc
+
+  $ echo 'ignored-file' > .hgignore
+  $ hg ci -qAm 0
+
+  $ echo 'c' > clean-file
+  $ echo 'a' > added-file
+  $ echo '?' > unknown-file
+  $ echo 'i' > ignored-file
+  $ hg add clean-file added-file
+  $ hg ci -m 1 clean-file
+  A added-file
+  ? unknown-file
+  $ hg st -mardu
+  A added-file
+  ? unknown-file
+
+  $ touch modified-file
+  $ hg add modified-file
+  $ hg ci -m 2 modified-file -q
+
+  $ echo 'm' > modified-file
+  $ hg ci --amend -m 'reworded' -X 're:'
+  saved backup bundle to $TESTTMP/ci-post-st/.hg/strip-backup/*-amend.hg (glob)
+  M modified-file
+  A added-file
+  ? unknown-file
+  $ hg st -mardu
+  M modified-file
+  A added-file
+  ? unknown-file
+
+  $ cd ..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


[PATCH 1 of 2] tests: flatten repo structure in test-commit.t

2019-05-03 Thread Anton Shestakov
# HG changeset patch
# User Anton Shestakov 
# Date 1556863634 -28800
#  Fri May 03 14:07:14 2019 +0800
# Node ID 49d7c0579df397ff05941d09ce97967e6ca9d53e
# Parent  fdbeacb9d456c0b98b00df66a9921fd884826cf1
# EXP-Topic post-commit-status
tests: flatten repo structure in test-commit.t

Let's move to parent directory before `hg init` repos, since they don't need to
be nested. It makes amend/strip messages that include full path to the backup
bundle shorter, for instance.

diff --git a/tests/test-commit.t b/tests/test-commit.t
--- a/tests/test-commit.t
+++ b/tests/test-commit.t
@@ -708,6 +708,8 @@ verify pathauditor blocks evil filepaths
   abort: path contains illegal component: HG8B6C~2/hgrc
   [255]
 
+  $ cd ..
+
 # test that an unmodified commit template message aborts
 
   $ hg init unmodified_commit_template
@@ -734,6 +736,8 @@ verify pathauditor blocks evil filepaths
   abort: commit message unchanged
   [255]
 
+  $ cd ..
+
 test that text below the --- >8 --- special string is ignored
 
   $ cat <<'EOF' > $TESTTMP/lowercaseline.sh
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6122: tests: add a file listing all the flaky tests

2019-03-21 Thread av6 (Anton Shestakov)
av6 added a comment.


  In https://phab.mercurial-scm.org/D6122#89818, @lothiraldan wrote:
  
  > @av6 is a `--no-flaky-tests` flag what you had in mind?
  
  
  Something like that, yes. I suggested that flag seeing how this change 
introduces a quite specific file with just one line. And I thought "if it's 
important, let's integrate it deeper into the test runner".
  
  But a flag for run-tests.py is not the only alternative. Now that I think 
about `#require`, can ​test-remotefilelog-bgprefetch.t be marked with `#require 
not-an-exotic-fs-inside-docker` (or whatever the actual thing that causes 
flakiness if it's known)? hghave.py already checks various filesystem features, 
why not make it check for the cause of issue6083?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6122

To: lothiraldan, #hg-reviewers
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] wix: restore COPYING.rtf

2019-03-18 Thread Anton Shestakov
On Sun, 17 Mar 2019 10:22:11 -0700
Gregory Szorc  wrote:

> # HG changeset patch
> # User Gregory Szorc 
> # Date 1552069233 28800
> #  Fri Mar 08 10:20:33 2019 -0800
> # Node ID 577eab065a686f838bf13def7810d8d6f5f7f7ec
> # Parent  7e95ade0f369d7509d04d6c0eefc06ca3d26c6e7
> wix: restore COPYING.rtf
> 
> 8427fea04017 accidentally blew away the content of this file.
> As part of restoring the content, I updated the copyright year
> to 2019.
> 
> Differential Revision: https://phab.mercurial-scm.org/D6098

This is mildly upsetting. I totally had COPYING.rtf in order when I
sent that patch, but https://phab.mercurial-scm.org/D5779 refuses to
show the diff saying it's a binary file, so I can't even see when the
issue occurred: somewhere in phabsend/phabricator or during
rebase/accept process. Anyway, thanks for fixing this.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH 1 of 2 STABLE] test-https: turn off system OpenSSL configuration

2019-03-17 Thread Anton Shestakov
On Sun, 17 Mar 2019 12:56:44 +0900
Yuya Nishihara  wrote:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1552793877 -32400
> #  Sun Mar 17 12:37:57 2019 +0900
> # Branch stable
> # Node ID 13ee301f9ecedcb8b087c1e71dc535fa1fdf19be
> # Parent  25fc5b96d1c30468417ee0d690c2979db362edd0
> test-https: turn off system OpenSSL configuration
> 
> This mostly fixes the test failure on Debian sid where TLS 1.0 and 1.1 are
> disabled by default.

Fixes test-https.t on Debian testing here. Series LGTM.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: [PATCH] repoview: introduce "served-obsolete" filter for serving obsolete changesets

2019-03-16 Thread Anton Shestakov
On Fri, 15 Mar 2019 16:59:22 +0300
Pulkit Goyal <7895pul...@gmail.com> wrote:

> On Tue, Mar 5, 2019 at 9:00 AM Anton Shestakov  wrote:
> 
> > # HG changeset patch
> > # User Anton Shestakov 
> > # Date 1551763152 -28800
> > #  Tue Mar 05 13:19:12 2019 +0800
> > # Node ID b6636687c713bf3c4b4c246b0e8759061d6e6742
> > # Parent  82d9728ace9535057d77df6c920385861ec00072
> > repoview: introduce "served-obsolete" filter for serving obsolete
> > changesets
> >
> > This filter allows viewing and pulling obsolete changesets (e.g. through
> > hgweb), but still doesn't allow secret commits to be seen. In other words,
> > this
> > is "served" plus obsolete commits, hence the name.
> >  
> 
> Is this also equivalent to (unfiltered-secret) commits?

Is "unfiltered-secret" an actual thing that exists? I couldn't find
anything with that name in hg. If it's a pseudo-revset, then yes,
"served-obsolete" is all changesets (unfiltered repo) minus secret
(that includes archived and internal).

"served-obsolete" is not "served" minus "obsolete", however: it's
served plus obsolete. I don't know if "served+obsolete" is a better
name, but test-obsolete.t passes with either of them.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6123: ZeroDivisionError: Add condition to avoid Zerodivisonerror due to float number (issue6099)

2019-03-13 Thread av6 (Anton Shestakov)
av6 added a comment.


  Okay, let's go over #1 in 
https://www.mercurial-scm.org/wiki/ContributingChanges#Submission_checklist 
once more. If you want to know what a good "topic" is, look at what other 
people do. How patches that get accepted generally look. How bug-fixing commits 
are worded.
  
  Secondly, about that capitalization. I'm sorry if this is some sort of silly 
autocorrect that's doing it for you, I really hope you're not writing commit 
messages on a phone.

INLINE COMMENTS

> similar.py:66-67
>  lengths = len(text) + len(orig)
> -return equal * 2.0 / lengths
> +if lengths > 0:
> +return equal * 2.0 / lengths
>  

`None > 1` is still an issue, see my comment above.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6123

To: akshjain.jain74, durin42, #hg-reviewers
Cc: av6, pulkit, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6123: Experimental features: Add condition to for float number (issue6099)

2019-03-13 Thread av6 (Anton Shestakov)
av6 added inline comments.

INLINE COMMENTS

> similar.py:67
> +if lengths > 0:
>  return equal * 2.0 / lengths
>  

This returns None in some cases, and code that uses `_score()` and `score()` 
tries to compare it to an integer. In Python3 `None > 1` raises TypeError.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6123

To: akshjain.jain74, durin42, #hg-reviewers
Cc: av6, pulkit, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6123: Experimental features: Add condition to for float number (issue6099)

2019-03-13 Thread av6 (Anton Shestakov)
av6 added a comment.


  I find it troubling that we now have contributors that don't follow #1 in 
https://www.mercurial-scm.org/wiki/ContributingChanges#Submission_checklist. 
Potentially #4 too (as Pulkit commented).
  
  Seriously, the title is terrible at describing what this patch fixes and 
where. The commit message could briefly mention why/when this condition is even 
required.

INLINE COMMENTS

> similar.py:66-67
>  lengths = len(text) + len(orig)
> +if lengths > 0:
>  return equal * 2.0 / lengths
>  

This is some... interesting syntax. Is this valid Python?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6123

To: akshjain.jain74, durin42, #hg-reviewers
Cc: av6, pulkit, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


D6122: tests: add a file listing all the flaky tests

2019-03-12 Thread av6 (Anton Shestakov)
av6 added a comment.


  Another way to do this could be to introduce another special keyword, similar 
to "slow", so that tests that are known flaky can `#require flaky` or even mark 
a specific block with `#if flaky`. Obviously fixing 
​test-remotefilelog-bgprefetch.t is a better idea altogether, but I'm not going 
to claim that it's easy.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D6122

To: lothiraldan, #hg-reviewers
Cc: av6, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


  1   2   3   4   5   >