Re: [PATCH] who: remove OpenJDK

[Josef 'Jeff' Sipek]

On Fri, Jul 31, 2020 at 18:30:57 +0200, Antonio Muci wrote:
> > Il 31/07/2020 17:55 Pierre-Yves David  ha 
> > scritto:
...
> > Moving to a modern Mercurial version, using sparse revlog for storage 
> > and recomputing delta gave a massive boost to storage size and clone 
> > performance.
> 
> At least this reassures that performance-wise mercurial has not fallen
> behind so much.
> The tests performed by Josef and Joerg confirm that a performance
> disadvantage exists indeed, but it's not massive.

Keep in mind that I did only clone testing.  I use both hg and git (hg
because I want to, git because I have to), and I have to admit that
something as simple as 'hg log' / 'git log' feel completely different.
git's log output feel instantaneously on the screen, while hg's takes a
fraction of a second.  It is a small fraction, but it "feels" slower.  I
think this has been diagnosed over and over as slow python startup.

...
> What concerns me the most are two things:
> 
> 1. scripta manent: when in some years people will google for "mercurial
> performance" they will stumble upon JDK considerations, and take them form
> granted. What will remain in a potential user's head is "mercurial is
> slow, go for git. JDK guys have done the same". There is no other written
> material counterweighting these moves (except for very interesting blog
> entries by Gregory Szorc, possibly), and so the collective mindset slowly
> slips away.

Around 2010, I messed quite a bit with the xfs file system in linux.  It was
really annoying that users found "tuning guide" slashdot posts from
2001-2003 that were completely wrong but they still kept finding them and
using them.  Often, this resulted in worse performance but the users were
also bad at benchmarking so they didn't notice until it was too late and
they file systems had a lot of data.  (I think it has gotten better, but
those horrid guides are still out there.)  In other words, it takes a *lot*
of effort to make sure people on the internet don't find misinformation.  I
don't really know how, but I think it needs to be a concentrated effort to
be "louder" than the misinformation.  (I consider outdated information
misinformation.)

Jeff.

-- 
All science is either physics or stamp collecting.
- Ernest Rutherford
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D8858: packaging: include templates with their package as key in package_data

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  This is similar to an earlier patch in this series. It seems more
  correct to use `mercurial.templates.coal` etc as keys in the
  `package_data` dict now that those modules are packages.

REPOSITORY
  rHG Mercurial

BRANCH
  default

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

AFFECTED FILES
  setup.py

CHANGE DETAILS

diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -1638,10 +1638,8 @@
 
 for root in ('templates',):
 for curdir, dirs, files in os.walk(os.path.join('mercurial', root)):
-curdir = curdir.split(os.sep, 1)[1]
-for f in filter(ordinarypath, files):
-f = os.path.join(curdir, f)
-packagedata['mercurial'].append(f)
+packagename = curdir.replace(os.sep, '.')
+packagedata[packagename] = list(filter(ordinarypath, files))
 
 datafiles = []
 



To: 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

D8857: packaging: delete unnecessary updating of `dirs` list

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  The `dirs` list is not used and it seems it also wasn't used when this
  code was added in 395b0e132836 
 
(Don't copy hidden files/directories
  during `setup.py install`, 2009-07-14).

REPOSITORY
  rHG Mercurial

BRANCH
  default

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

AFFECTED FILES
  setup.py

CHANGE DETAILS

diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -1639,7 +1639,6 @@
 for root in ('templates',):
 for curdir, dirs, files in os.walk(os.path.join('mercurial', root)):
 curdir = curdir.split(os.sep, 1)[1]
-dirs[:] = filter(ordinarypath, dirs)
 for f in filter(ordinarypath, files):
 f = os.path.join(curdir, f)
 packagedata['mercurial'].append(f)



To: 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

D8856: packaging: make "mercurial.defaultrc" a key in package_data

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Before this patch, we had a `mercurial` key with a `defaultrc/*.rc`
  value. It seems more correct to have a `mercurial.defaultrc` key with
  a `*.rc` value since `mercurial.defaultrc` it became a pacakge in
  1390bb81163e 
 
(help: get helptext/ data from `resources` module if
  available, 2019-12-12).

REPOSITORY
  rHG Mercurial

BRANCH
  default

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

AFFECTED FILES
  setup.py

CHANGE DETAILS

diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -1624,9 +1624,9 @@
 packagedata = {
 'mercurial': [
 'locale/*/LC_MESSAGES/hg.mo',
-'defaultrc/*.rc',
 'dummycert.pem',
 ],
+'mercurial.defaultrc': ['*.rc',],
 'mercurial.helptext': ['*.txt',],
 'mercurial.helptext.internals': ['*.txt',],
 }



To: 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

D8855: packaging: mark mercurial.templates and subdirs as packages

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  We need these packages to be installed so PyOxidizer picks them up.

REPOSITORY
  rHG Mercurial

BRANCH
  default

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

AFFECTED FILES
  setup.py

CHANGE DETAILS

diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -1268,6 +1268,7 @@
 'mercurial.hgweb',
 'mercurial.interfaces',
 'mercurial.pure',
+'mercurial.templates',
 'mercurial.thirdparty',
 'mercurial.thirdparty.attr',
 'mercurial.thirdparty.zope',
@@ -1292,6 +1293,13 @@
 'hgext3rd',
 'hgdemandimport',
 ]
+
+for name in os.listdir(os.path.join('mercurial', 'templates')):
+if name != '__pycache__' and os.path.isdir(
+os.path.join('mercurial', 'templates', name)
+):
+packages.append('mercurial.templates.%s' % name)
+
 if sys.version_info[0] == 2:
 packages.extend(
 [



To: 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

D8854: templates: add __init__.py files to templates/ dirs

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  This is necessary for them to be loaded with `importlib.resources`,
  which we want to do for PyOxidizer and similar. `importlib.resources`
  cannot read resources from submodules
  (`resources.open_binary('mercurial.templates', 'coal/map')` is not
  valid), so we need one `__init__.py` per directory.

REPOSITORY
  rHG Mercurial

BRANCH
  default

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

AFFECTED FILES
  mercurial/templates/__init__.py
  mercurial/templates/atom/__init__.py
  mercurial/templates/coal/__init__.py
  mercurial/templates/gitweb/__init__.py
  mercurial/templates/json/__init__.py
  mercurial/templates/monoblue/__init__.py
  mercurial/templates/paper/__init__.py
  mercurial/templates/raw/__init__.py
  mercurial/templates/rss/__init__.py
  mercurial/templates/spartan/__init__.py
  mercurial/templates/static/__init__.py

CHANGE DETAILS

diff --git a/mercurial/templates/static/__init__.py 
b/mercurial/templates/static/__init__.py
new file mode 100644
diff --git a/mercurial/templates/spartan/__init__.py 
b/mercurial/templates/spartan/__init__.py
new file mode 100644
diff --git a/mercurial/templates/rss/__init__.py 
b/mercurial/templates/rss/__init__.py
new file mode 100644
diff --git a/mercurial/templates/raw/__init__.py 
b/mercurial/templates/raw/__init__.py
new file mode 100644
diff --git a/mercurial/templates/paper/__init__.py 
b/mercurial/templates/paper/__init__.py
new file mode 100644
diff --git a/mercurial/templates/monoblue/__init__.py 
b/mercurial/templates/monoblue/__init__.py
new file mode 100644
diff --git a/mercurial/templates/json/__init__.py 
b/mercurial/templates/json/__init__.py
new file mode 100644
diff --git a/mercurial/templates/gitweb/__init__.py 
b/mercurial/templates/gitweb/__init__.py
new file mode 100644
diff --git a/mercurial/templates/coal/__init__.py 
b/mercurial/templates/coal/__init__.py
new file mode 100644
diff --git a/mercurial/templates/atom/__init__.py 
b/mercurial/templates/atom/__init__.py
new file mode 100644
diff --git a/mercurial/templates/__init__.py b/mercurial/templates/__init__.py
new file mode 100644



To: 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

D8853: templatespec: use new factory functions in hooklib

[martinvonz (Martin von Zweigbergk)]

martinvonz 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/D8853

AFFECTED FILES
  hgext/hooklib/changeset_obsoleted.py
  hgext/hooklib/changeset_published.py

CHANGE DETAILS

diff --git a/hgext/hooklib/changeset_published.py 
b/hgext/hooklib/changeset_published.py
--- a/hgext/hooklib/changeset_published.py
+++ b/hgext/hooklib/changeset_published.py
@@ -26,6 +26,7 @@
 from mercurial import (
 encoding,
 error,
+formatter,
 logcmdutil,
 mail,
 pycompat,
@@ -61,7 +62,7 @@
 b'notify_published', b'messageidseed'
 ) or ui.config(b'notify', b'messageidseed')
 template = ui.config(b'notify_published', b'template')
-spec = logcmdutil.templatespec(template, None)
+spec = formatter.literal_templatespec(template)
 templater = logcmdutil.changesettemplater(ui, repo, spec)
 ui.pushbuffer()
 n = notify.notifier(ui, repo, b'incoming')
diff --git a/hgext/hooklib/changeset_obsoleted.py 
b/hgext/hooklib/changeset_obsoleted.py
--- a/hgext/hooklib/changeset_obsoleted.py
+++ b/hgext/hooklib/changeset_obsoleted.py
@@ -26,6 +26,7 @@
 from mercurial import (
 encoding,
 error,
+formatter,
 logcmdutil,
 mail,
 obsutil,
@@ -62,7 +63,7 @@
 b'notify_obsoleted', b'messageidseed'
 ) or ui.config(b'notify', b'messageidseed')
 template = ui.config(b'notify_obsoleted', b'template')
-spec = logcmdutil.templatespec(template, None)
+spec = formatter.literal_templatespec(template)
 templater = logcmdutil.changesettemplater(ui, repo, spec)
 ui.pushbuffer()
 n = notify.notifier(ui, repo, b'incoming')



To: 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

Re: Proposal for cleaning up error reporting

[Augie Fackler]

> On Jul 31, 2020, at 13:26, Pierre-Yves David  
> wrote:
> 
> 
> 
> On 7/21/20 7:57 AM, Rodrigo Damazio wrote:
>> On Thu, Jul 16, 2020 at 9:09 AM Pierre-Yves David 
>> mailto:pierre-yves.da...@ens-lyon.org>> 
>> wrote:
>>The first time I saw this proposal I though:
>>- That is a great idea, I have been unhappy about these return for a
>>long time
>>- The backward compatibility breakage implication might be huge. We
>>probably need to gate this behind config at first.
>> I'm fine with gating some part of it by a config knob, and will leave it up 
>> to the community to decide when to break backwards compatibility in the 
>> future.
>>- The proposal is over all good but I have a couple of adjustement and
>>improvement in mind.
>> Would love to hear your thoughts.
>> And from Google's perspective, I don't feel too strongly about the return 
>> codes - I added it because it made sense to have an end-to-end design.
>> What we'll likely do is intercept the exceptions in our extension and report 
>> any failures by type to our servers, rather than relying on the actual codes.
> Here are some quick through I got by browsing the document again.
> 
> Input: There are different type of input failure, it would be nice to 
> distinct between them. For example:
> 
>  - revset is invalid and cannot be parsed
>  - revset reference an unknown revision/name
>  - revset is empty (or anything wrong for the input).
> 
> Configuration: unsupported requires should probably be its own exception. 
> having a clear signal of "I recognise that I cannot deal with the 
> reppository" is important. There could be some overlap (either the same error 
> or a similar one) with what we do with the Rust fastpath.
> 
> Remote: It would be nice if the remote return code could match the local one 
> (so, the one raised on the server). with and extra bit set. eg: code 20 
> locally would become code 84 if raised remotely.

Oooh now that's clever. I like it.

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

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

D8347: encoding: use special dictionary type for env variables on Windows

[baymax (Baymax, Your Personal Patch-care Companion)]

Herald added a subscriber: mercurial-patches.
This revision now requires changes to proceed.
baymax added a comment.
baymax requested changes to this revision.


  There seems to have been no activities on this Diff for the past 3 Months.
  
  By policy, we are automatically moving it out of the `need-review` state.
  
  Please, move it back to `need-review` without hesitation if this diff should 
still be discussed.
  
  :baymax:need-review-idle:

REPOSITORY
  rHG Mercurial

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

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

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

D8345: tests: look for CRLF on Windows

[baymax (Baymax, Your Personal Patch-care Companion)]

Herald added a subscriber: mercurial-patches.
This revision now requires changes to proceed.
baymax added a comment.
baymax requested changes to this revision.


  There seems to have been no activities on this Diff for the past 3 Months.
  
  By policy, we are automatically moving it out of the `need-review` state.
  
  Please, move it back to `need-review` without hesitation if this diff should 
still be discussed.
  
  :baymax:need-review-idle:

REPOSITORY
  rHG Mercurial

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

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

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

D8346: tests: force newlines to LF in tinyproxy.py

[baymax (Baymax, Your Personal Patch-care Companion)]

Herald added a subscriber: mercurial-patches.
This revision now requires changes to proceed.
baymax added a comment.
baymax requested changes to this revision.


  There seems to have been no activities on this Diff for the past 3 Months.
  
  By policy, we are automatically moving it out of the `need-review` state.
  
  Please, move it back to `need-review` without hesitation if this diff should 
still be discussed.
  
  :baymax:need-review-idle:

REPOSITORY
  rHG Mercurial

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

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

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

D8348: tests: force newlines to LF in inline Python script

[baymax (Baymax, Your Personal Patch-care Companion)]

Herald added a subscriber: mercurial-patches.
This revision now requires changes to proceed.
baymax added a comment.
baymax requested changes to this revision.


  There seems to have been no activities on this Diff for the past 3 Months.
  
  By policy, we are automatically moving it out of the `need-review` state.
  
  Please, move it back to `need-review` without hesitation if this diff should 
still be discussed.
  
  :baymax:need-review-idle:

REPOSITORY
  rHG Mercurial

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

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

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

D5496: revset: add "samebranch" keyword argument to the merge revset

[baymax (Baymax, Your Personal Patch-care Companion)]

This revision now requires changes to proceed.
baymax added a comment.
baymax requested changes to this revision.


  There seems to have been no activities on this Diff for the past 3 Months.
  
  By policy, we are automatically moving it out of the `need-review` state.
  
  Please, move it back to `need-review` without hesitation if this diff should 
still be discussed.
  
  :baymax:need-review-idle:

REPOSITORY
  rHG Mercurial

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

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

To: angel.ezquerra, #hg-reviewers, baymax
Cc: mercurial-patches, marmoute, mharbison72, yuja, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D6312: branchcache: update the filteredhash if we update the tiprev

[baymax (Baymax, Your Personal Patch-care Companion)]

This revision now requires changes to proceed.
baymax added a comment.
baymax requested changes to this revision.


  There seems to have been no activities on this Diff for the past 3 Months.
  
  By policy, we are automatically moving it out of the `need-review` state.
  
  Please, move it back to `need-review` without hesitation if this diff should 
still be discussed.
  
  :baymax:need-review-idle:

REPOSITORY
  rHG Mercurial

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

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

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

Re: [PATCH 02 of 13] mergestate: remove unrequired RECORD_RESOLVED_OTHER record

[Pierre-Yves David]

On 7/19/20 11:11 AM, Yuya Nishihara wrote:

On Fri, 17 Jul 2020 14:29:23 +0530, Pulkit Goyal wrote:

# HG changeset patch
# User Pulkit Goyal <7895pul...@gmail.com>
# Date 1594290002 -19800
#  Thu Jul 09 15:50:02 2020 +0530
# Node ID 9e4a5e41f0ac3fa39a29d5376a1d3922e9221318
# Parent  66fb1ff9343a4d73b44c4314d88176e283a7839d
# EXP-Topic mergestate-refactor
mergestate: remove unrequired RECORD_RESOLVED_OTHER record

This was introduced in last cycle however while working on refactoring
mergestate, I realized it's unncessary.

This will break users who did a merge using previous version, did this kind of
storage and before commiting updated the mercurial version.


Maybe better to document it and what error would be displayed in the release
notes.


It is probably not even worse breaking user of this. We could have a set 
of LEGACY record that we can safely ignore.


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

Re: Proposal for cleaning up error reporting

[Pierre-Yves David]

On 7/21/20 7:57 AM, Rodrigo Damazio wrote:
On Thu, Jul 16, 2020 at 9:09 AM Pierre-Yves David 
mailto:pierre-yves.da...@ens-lyon.org>> 
wrote:


The first time I saw this proposal I though:

- That is a great idea, I have been unhappy about these return for a
long time

- The backward compatibility breakage implication might be huge. We
probably need to gate this behind config at first.


I'm fine with gating some part of it by a config knob, and will leave it 
up to the community to decide when to break backwards compatibility in 
the future.


- The proposal is over all good but I have a couple of adjustement and
improvement in mind.


Would love to hear your thoughts.

And from Google's perspective, I don't feel too strongly about the 
return codes - I added it because it made sense to have an end-to-end 
design.
What we'll likely do is intercept the exceptions in our extension and 
report any failures by type to our servers, rather than relying on the 
actual codes.

Here are some quick through I got by browsing the document again.

Input: There are different type of input failure, it would be nice to 
distinct between them. For example:


  - revset is invalid and cannot be parsed
  - revset reference an unknown revision/name
  - revset is empty (or anything wrong for the input).

Configuration: unsupported requires should probably be its own 
exception. having a clear signal of "I recognise that I cannot deal with 
the reppository" is important. There could be some overlap (either the 
same error or a similar one) with what we do with the Rust fastpath.


Remote: It would be nice if the remote return code could match the local 
one (so, the one raised on the server). with and extra bit set. eg: code 
20 locally would become code 84 if raised remotely.


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

Re: [PATCH] who: remove OpenJDK

[Joerg Sonnenberger]

On Fri, Jul 31, 2020 at 06:30:57PM +0200, Antonio Muci via Mercurial-devel 
wrote:
> What concerns me the most are two things:
> 
> 1. scripta manent: when in some years people will google for "mercurial
> performance" they will stumble upon JDK considerations, and take them
> form granted. What will remain in a potential user's head is "mercurial
> is slow, go for git. JDK guys have done the same". There is no other
> written material counterweighting these moves (except for very
> interesting blog entries by Gregory Szorc, possibly), and so the
> collective mindset slowly slips away.

I fully agree with the problem and I've had to deal with the same issue
before. I consider the write-up from the OpenJDK people to be quite
dishonest, but there is little that we can do about it.

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

Re: [PATCH] who: remove OpenJDK

[Pierre-Yves David]

On 7/31/20 6:30 PM, Antonio Muci wrote:

I am wondering if the countermeasures to this have to be only technical. I see 
this more as a communication disadvantage compared to the git ecosystem.


We could definitely use more communication :-/

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

Re: [PATCH] who: remove OpenJDK

[Antonio Muci via Mercurial-devel]

> Il 31/07/2020 17:55 Pierre-Yves David  ha 
> scritto:
>
> I got int touch with the OpenJDK people one and half year ago. [...]

Very active move on your part. Kudos.


> Moving to a modern Mercurial version, using sparse revlog for storage 
> and recomputing delta gave a massive boost to storage size and clone 
> performance.

At least this reassures that performance-wise mercurial has not fallen behind 
so much.
The tests performed by Josef and Joerg confirm that a performance disadvantage 
exists indeed, but it's not massive.

> a good share was also lack of interrest in 
> actually improves their Mercurial situation. The crave to move to Github
> for community reason was strong.

I can understand wanting to benefit of the Github network effect, and do not 
want to focus on it here.

What concerns me the most are two things:


1. scripta manent: when in some years people will google for "mercurial 
performance" they will stumble upon JDK considerations, and take them form 
granted. What will remain in a potential user's head is "mercurial is slow, go 
for git. JDK guys have done the same". There is no other written material 
counterweighting these moves (except for very interesting blog entries by 
Gregory Szorc, possibly), and so the collective mindset slowly slips away.

2. (consequence of 1) no mindset that another valid SCM exists: SCM == GitHub, 
because - obviously - git == "hosted service with integrated issue tracker, CI 
and whatnot", right?

I am wondering if the countermeasures to this have to be only technical. I see 
this more as a communication disadvantage compared to the git ecosystem.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] who: remove OpenJDK

[Pierre-Yves David]

On 7/25/20 7:36 PM, Josef 'Jeff' Sipek wrote:

On Sat, Jul 25, 2020 at 12:27:42 +0200, Antonio Muci via Mercurial-devel wrote:

That's sad.


Yeah.

This motivated me enough to clone the repos (hg and git) and collect some
data.  Maybe people here will find it useful.
I got int touch with the OpenJDK people one and half year ago. The 
verison of Mercurial they use on the server is extremely old. The 
repository format they use is ancient (not even general delta IIRC).


Moving to a modern Mercurial version, using sparse revlog for storage 
and recomputing delta gave a massive boost to storage size and clone 
performance.


However I never managed to get to even simply upgrade their mercurial 
server side. Some of the issue OpenJDK had were legitimate concerns that 
we could improve, but a good share was also lack of interrest in 
actually improves their Mercurial situation. The crave to move to Github 
for community reason was strong.


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

[Bug 6393] New: Using HG 5.2 and the corresponding evolve version (33c33a373da6) no fast forward does not work

[mercurial-bugs]

https://bz.mercurial-scm.org/show_bug.cgi?id=6393

Bug ID: 6393
   Summary: Using HG 5.2 and the corresponding evolve version
(33c33a373da6) no fast forward does not work
   Product: Mercurial
   Version: earlier
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: evolution
  Assignee: bugzi...@mercurial-scm.org
  Reporter: oub.oub@gmail.com
CC: mercurial-devel@mercurial-scm.org,
pierre-yves.da...@ens-lyon.org
Python Version: ---

Steps to reproduce 
hg init
echo "First" > test.org
hg add test.org
hg commit -u "Bernhard Riemann " -m "First"
echo "Second" >> test.org
hg commit -u "Bernhard Riemann " -m "Second"
echo "Third" >> test.org
hg commit -u "Bernhard Riemann " -m "Third"
echo "Forth" >> test.org
hg commit  -m "Fourth"
hg topics NewTopic
echo "Fifth" >> test.org
hg commit  -m "Fifth"
echo "Six" >> test.org
hg commit  -m "Six"
hg up 3 
hg merge NewTopic



This work if I use a named branch instead of a topic

Pierre-Yves told me to send this bug report
regards

Uwe Brauer

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH STABLE] dispatch: adjust ui.flush() timing to stabilize test-blackbox.t

[Pulkit Goyal]

On Sat, Jul 25, 2020 at 7:59 PM Yuya Nishihara  wrote:
>
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1595685086 -32400
> #  Sat Jul 25 22:51:26 2020 +0900
> # Branch stable
> # Node ID cd333962901c4142d6b29deae1851bca6c51f587
> # Parent  41021660baa1bdb3fb089d6ddb6b6658c9e540b1
> dispatch: adjust ui.flush() timing to stabilize test-blackbox.t
>
> Without this change, dispatch.dispatch() could return before flushing all
> stdio data. This means chg stdio would print data after receiving the result
> code.

Thanks a lot for looking into this. Queued for stable, many thanks!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 01 of 15] commitctx: explicitly pass `manifest` to _commit_manifest

[Pulkit Goyal]

On Wed, Jul 29, 2020 at 10:44 PM Pierre-Yves David
 wrote:
>
> # HG changeset patch
> # User Pierre-Yves David 
> # Date 1596030013 -7200
> #  Wed Jul 29 15:40:13 2020 +0200
> # Node ID 0ff421a458680435f7a39c770cfa5823961cd314
> # Parent  13814622b3b1a46308375a9fb4c6641fa495528f
> # EXP-Topic files-change
> # Available At https://foss.heptapod.net/octobus/mercurial-devel/
> #  hg pull https://foss.heptapod.net/octobus/mercurial-devel/ -r 
> 0ff421a45868
> commitctx: explicitly pass `manifest` to _commit_manifest
>
> As pointed out by Yuya Nishihara.

Queued 1 to 5, many thanks!
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel