Re: [PATCH remotenames-ext] push: better job checking for git or svn path
Ryan McElroy writes: > # HG changeset patch > # User Ryan McElroy > # Date 1492609910 25200 > # Wed Apr 19 06:51:50 2017 -0700 > # Node ID 3fbe113a35b8686b08d5288f8be8ace9ef9a > # Parent e3d4101c550fbbcc5089109f078be905b9d729de > push: better job checking for git or svn path Looks good. Queued. signature.asc Description: PGP signature ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: stable ordering of test output
On Wed, 19 Apr 2017 15:22:42 -0400, Augie Fackler wrote: > On Sat, Apr 15, 2017 at 1:04 PM, Augie Fackler wrote: > > > >> On Apr 15, 2017, at 5:48 AM, Yuya Nishihara wrote: > >> > >> On Thu, 13 Apr 2017 16:17:34 -0400, Augie Fackler wrote: > >>> # HG changeset patch > >>> # User Augie Fackler > >>> # Date 1492114180 14400 > >>> # Thu Apr 13 16:09:40 2017 -0400 > >>> # Node ID ec81fd7580f3e31aa92e8834ffbcf2a8e80e72e3 > >>> # Parent 35afb54dbb4df2975dbbf0e1525b98611f18ba85 > >>> sshpeer: try harder to snag stderr when stdout closes unexpectedly > >>> > >>> Resolves test failures on FreeBSD, but I'm not happy about the fix. > >>> > >>> diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py > >>> --- a/mercurial/sshpeer.py > >>> +++ b/mercurial/sshpeer.py > >>> @@ -110,9 +110,17 @@ class doublepipe(object): > >>> if mainready: > >>> meth = getattr(self._main, methname) > >>> if data is None: > >>> -return meth() > >>> +r = meth() > >>> else: > >>> -return meth(data) > >>> +r = meth(data) > >>> +if not r and data != 0: > >> > >> I'm not sure what this condition is intended for. It's always true for > >> write() because r is None and data is a str. > > > > This forwarder is also used for read(), where data is the number of bytes > > to be read. At least, I think that’s right, now I’m doubting myself. > > Should I go ahead and mail this patch? Perhaps with some extra > comments? Or do people object to this fix? Seems fine, but can you update the patch to not always call _forwardoutput() by write() ? Perhaps this hack can be moved to read() and readline(). ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH RFC] tests: remaining Windows failures
Excerpts from Matt Harbison's message of 2017-04-19 23:04:17 -0400: > [...] > diff --git a/tests/test-worker.t b/tests/test-worker.t > --- a/tests/test-worker.t > +++ b/tests/test-worker.t > @@ -81,7 +81,6 @@ >$ hg --config "extensions.t=$abspath" --config 'worker.numcpus=2' \ >> test 10.0 abort --traceback 2>&1 | grep '^Traceback' >Traceback (most recent call last): > - Traceback (most recent call last): This is because worker only works for POSIX. Related code are: if pycompat.osname == 'posix': _startupcost = 0.01 else: _startupcost = 1e30 def worthwhile(ui, costperop, nops): '''try to determine whether the benefit of multiple processes can outweigh the cost of starting them''' linear = costperop * nops workers = _numworkers(ui) benefit = linear - (_startupcost * workers + linear / workers) return benefit >= 0.15 worthwhile return False because benefit is negative. if pycompat.osname != 'nt': _platformworker = _posixworker _exitstatus = _posixexitstatus _platformworker is undefined on Windows. > > Traceback must be printed for unknown exceptions ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 1 of 2 STABLE] test-profile: allow negative time in JSON output (issue5542)
# HG changeset patch # User Yuya Nishihara # Date 1492695945 -32400 # Thu Apr 20 22:45:45 2017 +0900 # Branch stable # Node ID 86688d9fb4bcec3f4672aea9f2f94f5dd9af61c0 # Parent 59afb0750aecaff6c2b2e4edaab04eb91eca8a88 test-profile: allow negative time in JSON output (issue5542) I don't know why it can be a negative number, but that shouldn't be important here. diff --git a/tests/test-profile.t b/tests/test-profile.t --- a/tests/test-profile.t +++ b/tests/test-profile.t @@ -90,7 +90,7 @@ Various statprof formatters work $ hg --profile --config profiling.statformat=json sleep 2>../out $ cat ../out - \[\[\d+.* (re) + \[\[-?\d+.* (re) statprof can be used as a standalone module ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 2 of 2 STABLE] test-worker: disable tests of forked workers on Windows
# HG changeset patch # User Yuya Nishihara # Date 1492696288 -32400 # Thu Apr 20 22:51:28 2017 +0900 # Branch stable # Node ID 9ca22928766f4bafd8adb4f9a49625ca69a48c44 # Parent 86688d9fb4bcec3f4672aea9f2f94f5dd9af61c0 test-worker: disable tests of forked workers on Windows The number of the "Traceback" lines differs on Windows because the main process does not raise SystemExit. diff --git a/tests/test-worker.t b/tests/test-worker.t --- a/tests/test-worker.t +++ b/tests/test-worker.t @@ -70,6 +70,8 @@ Run tests without worker by forcing a lo run done +#if no-windows + Known exception should be caught, but printed if --traceback is enabled $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=2' \ @@ -88,3 +90,5 @@ Traceback must be printed for unknown ex $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=2' \ > test 10.0 exc 2>&1 | grep '^Traceback' Traceback (most recent call last): + +#endif ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 1 of 2 STABLE] worker: be silent if killed by the main process
# HG changeset patch
# User Jun Wu
# Date 1492704007 25200
# Thu Apr 20 09:00:07 2017 -0700
# Node ID f0bd43ca0d5659a1e49bf4948a9d3d0f30a69e34
# Parent 59afb0750aecaff6c2b2e4edaab04eb91eca8a88
# Available At https://bitbucket.org/quark-zju/hg-draft
# hg pull https://bitbucket.org/quark-zju/hg-draft -r f0bd43ca0d56
worker: be silent if killed by the main process
Previously, worker.py will send SIGTERM to remaining workers once a failure
of another worker is noticed. Workers receiving SIGTERM will go through
scmutil.callcatch, and may have extra outputs like "killed!" and a
traceback, which breaks test-worker.t.
Besides, it's hard to predicate how many "killed!" or traceback should be
printed if we keep that behavior.
Since the main process will notice a worker failure and handle it
accordingly, it makes sense to kill the remaining workers silently.
Therefore this patch adds a backdoor signal - SIGUSR2 to allow a silent
SIGTERM kill.
This makes test-worker.t less flaky. The next patch will make test-worker.t
stronger (and easier to break without this patch).
diff --git a/mercurial/worker.py b/mercurial/worker.py
--- a/mercurial/worker.py
+++ b/mercurial/worker.py
@@ -100,4 +100,6 @@ def _posixworker(ui, func, staticargs, a
for p in pids:
try:
+# SIGUSR2 makes a worker silent for the upcoming SIGTERM
+os.kill(p, signal.SIGUSR2)
os.kill(p, signal.SIGTERM)
except OSError as err:
@@ -135,4 +137,11 @@ def _posixworker(ui, func, staticargs, a
oldchldhandler = signal.signal(signal.SIGCHLD, sigchldhandler)
ui.flush()
+# when the main process notices an error (non-0 exit code), remaining
+# workers will be killed without causing noisy output ("killed!" and a
+# traceback). this is done by a special SIGUSR2.
+def silentsigterm(signum, frame):
+# avoid scmutil.callcatch code path which could be noisy
+signal.signal(signal.SIGTERM, signal.SIG_DFL)
+oldusr2handler = signal.signal(signal.SIGUSR2, silentsigterm)
for pargs in partition(args, workers):
pid = os.fork()
@@ -167,4 +176,5 @@ def _posixworker(ui, func, staticargs, a
os._exit(ret & 255)
pids.add(pid)
+signal.signal(signal.SIGUSR2, oldusr2handler)
os.close(wfd)
fp = os.fdopen(rfd, pycompat.sysstr('rb'), 0)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH 2 of 2 STABLE] test-worker: make the test stronger
# HG changeset patch
# User Jun Wu
# Date 1492704139 25200
# Thu Apr 20 09:02:19 2017 -0700
# Node ID 2131b2f373c93d6d6bfc834436208c36363b85cf
# Parent f0bd43ca0d5659a1e49bf4948a9d3d0f30a69e34
# Available At https://bitbucket.org/quark-zju/hg-draft
# hg pull https://bitbucket.org/quark-zju/hg-draft -r 2131b2f373c9
test-worker: make the test stronger
This patch makes it easier to exercise the "killworkers" code path, to
verify the fix of the former patch.
diff --git a/tests/test-worker.t b/tests/test-worker.t
--- a/tests/test-worker.t
+++ b/tests/test-worker.t
@@ -3,4 +3,5 @@ Test UI worker interaction
$ cat > t.py < from __future__ import absolute_import, print_function
+ > import time
> from mercurial import (
> cmdutil,
@@ -23,4 +24,5 @@ Test UI worker interaction
> ui.status('run\n')
> yield 1, arg
+ > time.sleep(0.1) # easier to trigger killworkers code path
> functable = {
> 'abort': abort,
@@ -73,11 +75,11 @@ Run tests without worker by forcing a lo
Known exception should be caught, but printed if --traceback is enabled
- $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=2' \
- > test 10.0 abort
+ $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=8' \
+ > test 10.0 abort 2>&1
start
abort: known exception
[255]
- $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=2' \
+ $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=8' \
> test 10.0 abort --traceback 2>&1 | grep '^Traceback'
Traceback (most recent call last):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH STABLE] discovery: prevent crash caused by prune marker having no parent data
Pierre-Yves David writes: > On 04/19/2017 04:45 PM, Yuya Nishihara wrote: >> # HG changeset patch >> # User Yuya Nishihara >> # Date 1492611005 -32400 >> # Wed Apr 19 23:10:05 2017 +0900 >> # Branch stable >> # Node ID 42fd230386fc31d24f3d580a6f09efe596cd516c >> # Parent 59afb0750aecaff6c2b2e4edaab04eb91eca8a88 >> discovery: prevent crash caused by prune marker having no parent data >> >> If a marker has no parent information, parents field is set to None, which >> caused TypeError. I think this shouldn't normally happen, but somehow > > This patch looks good to me. Yeah, looks good to me, too. signature.asc Description: PGP signature ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2] show: add basic labels to work template
Gregory Szorc writes: > # HG changeset patch > # User Gregory Szorc > # Date 1492539008 25200 > # Tue Apr 18 11:10:08 2017 -0700 > # Node ID 7f5f78179f5f6afc0f4bea52aa03f1431e03d3d9 > # Parent d8d4b4acc68859f90f8759309803b116b67a9371 > show: add basic labels to work template > > `hg show work` is much more usable if output is colored. This patch > implements coloring via label() in a very hacky way. > > In a default Mercurial install, you'll see yellow node labels for all > phases. Branches and bookmarks use the same formatting as the commit > message. So this change doesn't help much in a default install. But if > you have a custom colors defined for these things, output is much more > readable. > > The implementation obviously needs some work. But for a minor change > on a feature that isn't convered by BC, this seems like a clear win > for the feature in 4.2. Do we add this after the rc now? My guess is no but it does seem nice for 4.2 (shrug) signature.asc Description: PGP signature ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext] legacy: fix debugrecordpruneparents to call obsstore.create() with keywords
Yuya Nishihara writes: > # HG changeset patch > # User Yuya Nishihara > # Date 1492615273 -32400 > # Thu Apr 20 00:21:13 2017 +0900 > # Branch stable > # Node ID dfc33a94e1e6050d82d6df47b2cffb997f37cbd5 > # Parent eb47d436cdc3bc6657d89baffe24fcd9abaf9e9c > legacy: fix debugrecordpruneparents to call obsstore.create() with keywords > > It appears the API was changed twice in Mercurial at > > - 570f87422f54 "obsstore: add an explicit `date` argument to obsstore.create" > - adb3798dce49 "obsstore: add a `parents` argument to obsstore.create" > > and metadata would be changed to a list of (key, value) pairs. Convert it back > to a dict as expected by create(). Seems fine to me. signature.asc Description: PGP signature ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[Bug 5544] New: subrepo lost config options
https://bz.mercurial-scm.org/show_bug.cgi?id=5544 Bug ID: 5544 Summary: subrepo lost config options Product: Mercurial Version: default branch Hardware: All OS: All Status: UNCONFIRMED Severity: bug Priority: wish Component: Mercurial Assignee: bugzi...@mercurial-scm.org Reporter: arcppzju+hg...@gmail.com CC: mercurial-devel@mercurial-scm.org hg clone --config=extensions.lz4revlog=! repo The "--config extensions.lz4revlog=!" flag is effective for repo, but not effective for subrepos. -- 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
[Bug 5545] New: histedit with interrupted merge -> empty status causes dataloss
https://bz.mercurial-scm.org/show_bug.cgi?id=5545 Bug ID: 5545 Summary: histedit with interrupted merge -> empty status causes dataloss Product: Mercurial Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: bug Priority: wish Component: histedit Assignee: bugzi...@mercurial-scm.org Reporter: s...@fb.com CC: mercurial-devel@mercurial-scm.org Repro against ed42e00a5c4ec7a3bebaec699ef934429cdc2ddd (current @). $ cat >>$HGRCPATH < [extensions] > histedit= > EOF $ hg init foo $ cd foo $ echo one >> alpha $ hg addr adding alpha $ hg ci -m one $ echo two >> alpha $ hg ci -m two $ echo three >> alpha $ hg ci -m three $ hg log --style compact --graph @ 2[tip] a3884f37e029 1970-01-01 00:00 + test |three | o 1 c06dfaaa4216 1970-01-01 00:00 + test |two | o 0 7bed31acdb1e 1970-01-01 00:00 + test one $ hg histedit 0 --commands - 2>&1 << EOF > pick 7bed31acdb1e one > roll a3884f37e029 three > roll c06dfaaa4216 two > EOF 1 files updated, 0 files merged, 0 files removed, 0 files unresolved merging alpha warning: conflicts while merging alpha! (edit, then use 'hg resolve --mark') Fix up the change (roll a3884f37e029) (hg histedit --continue to resume) [1] $ hg histedit --continue abort: unresolved merge conflicts (see 'hg help resolve') [255] Make it so that 'hg status' is empty $ echo one > alpha $ hg status ? alpha.orig Note we run hg histedit --continue without running hg resolve -ma $ hg histedit --continue a3884f37e029: empty changeset abort: outstanding merge conflicts [255] Note the changeset this time is different $ hg histedit --continue c06dfaaa4216: empty changeset abort: outstanding merge conflicts [255] Note no changeset $ hg histedit --continue abort: outstanding merge conflicts [255] $ hg resolve -ma (no more unresolved files) continue: hg histedit --continue $ hg histedit --continue saved backup bundle to $TESTTMP/foo/.hg/strip-backup/c06dfaaa4216-ae0859b0-backup.hg (glob) The third action got lost $ echo alpha alpha $ hg log --style compact --graph @ 0[tip] 7bed31acdb1e 1970-01-01 00:00 + test one -- 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: Hidden Commits in 4.3
Durham Goode writes: > I respond below, but I believe Jun has sent you a innovative proposal > that may solve both of our needs and render this discussion irrelevant. > So take a look at his proposal at your earliest convenience, since it > may let us put this behind us. > > On 4/18/17 11:03 AM, Pierre-Yves David wrote: >> On 04/14/2017 01:04 AM, Durham Goode wrote: >>> On 4/13/17 2:37 PM, Pierre-Yves David wrote: On 04/12/2017 04:23 PM, Ryan McElroy wrote: > […] *Practical example* (/simplified/): Situation: * Facebook has a useful: hg undo command. * Facebook cares about hg undo, preserving the hash, * this hash preservation conflict with current constraint of changeset-evolution. Way forward: * Facebook can upstream hg undo with hash preservation, * We introduces a variant that changes the hash and makes it available to all users with BC, * Facebook can set the config for hash preservation internally. Result: the code is upstream, user has new feature and we can discuss hash preservation later. >>> >>> I think this example is missing the step where we discuss what we should >>> ship to users. My goal is not to enable Facebook to have a feature (we >>> already have these features), my goal is to create a good user >>> experience for Mercurial users. If we do the config knob route, we must >>> at some point have the discussion about what experience we want to give >>> to users, before we actually ship it to them. >>> >>> So in your proposal, when will it become appropriate to have that >>> discussion? And what can we do between now and then to make that >>> discussion more productive? I think we're blocked on getting bits into >>> the hands of users by default until then. >> >> (note: I've purposely delay more "discussion" oriented part in my other >> email (that you also replied to) I'll reply to it too shortly after this >> one.) >> >> >> In my example above, once "hg undo" is upstreamed, we are able to build >> a variant without hash preservation[1] and ship that the user by default >> without delay. > > I'm sure you don't mean it this way, but this sounds a lot like "let's > ship my thing and we'll figure your thing out later". The moment evolve > ships, it becomes a lot harder to make the types of changes I'm talking > about (both from a user experience point of view and community > momentum), so I'd rather have the discussion now while it's still > possible to make important changes. If we flipped the sentence around > (ship mine, figure yours out later) I'm sure you wouldn't be happy with > that outcome either. For what it's worth, I did not read it that way. Also, I've tried to avoid this discussion (across all the various threads) because it has been draining. >> On a general principle, decoupling implementation discussion from UI >> polishing is usually a win. > > If we decoupled UI from implementation here, we'd just go ahead and ship > "hg unhide" with hash preservation, since that's objectively the more > intuitive UI for unhide. But since the implementation of the obsolete > graph doesn't allow that UI, implementation therefore affects our > discussion. At first reading of this, I find this kind of hostile from Facebook. I'm sure you didn't mean it that way but eh. I found it hard to reply to this thread because of all the different derailings. For every non-Facebook dev here, there are so many more Facebook devs to reply to. That is exhausting. *I* am exhausted. > I'd love to discuss the pro's and con's of these two ideas purely from a > UX standpoint, but I haven't seen any concrete examples of situations > where evolve is affected by this for us to have a tangible discussion > around it. If we had a concrete example, we could more productively > evaluate the pro's and con's of these ideas. There's so much convolution in this thread. For instance, I think (fast) local hiding would be cool. A version of that is possible today and I've even had my hand at it: https://bitbucket.org/seanfarley/hgremotenames/commits/69cda2b8353ab1b108ca120d08eb253941f9ae70?at=hideable That's remarkably simple and having a bitmap (or whatever) api would be good. I'm surprised there has been so much misinformation and changing of the goal posts. For instance, * obs marker are global state I didn't think this was even a point to be contested. Distributed systems is difficult and evolve is solving a hard problem of shared rebase, histedit, etc. * hash preservation Sure, that's neat. But that's not a blocker. Like, not even a little bit. If I hear Jun say that obs-based hiding is broken by design one more time, I might roll my eyes so hard that they'll fall out the back of my skull. > Given that evolve has been around for years and people still aren't able > to reason about concrete examples in these discussions, I
[PATCH STABLE] histedit: make check for unresolved conflicts explicit (issue5545)
# HG changeset patch # User Siddharth Agarwal # Date 1492733888 25200 # Thu Apr 20 17:18:08 2017 -0700 # Node ID f368dbe9671ece414c842f164269e893521e3e5d # Parent ed42e00a5c4ec7a3bebaec699ef934429cdc2ddd histedit: make check for unresolved conflicts explicit (issue5545) Previously, we'd rely on the implicit check that `localrepo.commit` did. The problem is that that check only happened when the working copy was dirty. With a "clean" working copy but unresolved conflicts we'd get into a broken state. To fix that, do what rebase does and check for unresolved conflicts at the start of histedit --continue. diff --git a/hgext/histedit.py b/hgext/histedit.py --- a/hgext/histedit.py +++ b/hgext/histedit.py @@ -198,6 +198,7 @@ from mercurial import ( hg, lock, merge as mergemod, +mergeutil, node, obsolete, repair, @@ -1297,6 +1298,10 @@ def _getsummary(ctx): def bootstrapcontinue(ui, state, opts): repo = state.repo + +ms = mergemod.mergestate.read(repo) +mergeutil.checkunresolved(ms) + if state.actions: actobj = state.actions.pop(0) diff --git a/tests/test-histedit-non-commute.t b/tests/test-histedit-non-commute.t --- a/tests/test-histedit-non-commute.t +++ b/tests/test-histedit-non-commute.t @@ -161,12 +161,17 @@ fix up warning: conflicts while merging e! (edit, then use 'hg resolve --mark') Fix up the change (pick 7b4e2f4b7bcd) (hg histedit --continue to resume) + $ hg histedit --continue 2>&1 | fixbundle + abort: unresolved merge conflicts (see 'hg help resolve') This failure is caused by 7b4e2f4b7bcd "e" not rebasing the non commutative former children. just continue this time $ hg revert -r 'p1()' e +make sure the to-be-empty commit doesn't screw up the state (issue5545) + $ hg histedit --continue 2>&1 | fixbundle + abort: unresolved merge conflicts (see 'hg help resolve') $ hg resolve --mark e (no more unresolved files) continue: hg histedit --continue ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2 STABLE] test-worker: disable tests of forked workers on Windows
On Thu, 20 Apr 2017 11:09:41 -0400, Yuya Nishihara wrote: # HG changeset patch # User Yuya Nishihara # Date 1492696288 -32400 # Thu Apr 20 22:51:28 2017 +0900 # Branch stable # Node ID 9ca22928766f4bafd8adb4f9a49625ca69a48c44 # Parent 86688d9fb4bcec3f4672aea9f2f94f5dd9af61c0 test-worker: disable tests of forked workers on Windows The number of the "Traceback" lines differs on Windows because the main process does not raise SystemExit. Works for me, thanks. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH RFC] tests: remaining Windows failures
On Thu, 20 Apr 2017 10:42:50 -0400, Jun Wu wrote: Excerpts from Matt Harbison's message of 2017-04-19 23:04:17 -0400: [...] diff --git a/tests/test-worker.t b/tests/test-worker.t --- a/tests/test-worker.t +++ b/tests/test-worker.t @@ -81,7 +81,6 @@ $ hg --config "extensions.t=$abspath" --config 'worker.numcpus=2' \ > test 10.0 abort --traceback 2>&1 | grep '^Traceback' Traceback (most recent call last): - Traceback (most recent call last): This is because worker only works for POSIX. Related code are: if pycompat.osname == 'posix': _startupcost = 0.01 else: _startupcost = 1e30 def worthwhile(ui, costperop, nops): '''try to determine whether the benefit of multiple processes can outweigh the cost of starting them''' linear = costperop * nops workers = _numworkers(ui) benefit = linear - (_startupcost * workers + linear / workers) return benefit >= 0.15 worthwhile return False because benefit is negative. if pycompat.osname != 'nt': _platformworker = _posixworker _exitstatus = _posixexitstatus _platformworker is undefined on Windows. Thanks for the detailed explanation. Traceback must be printed for unknown exceptions ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Hidden Commits in 4.3
(So it’s not buried: Pierre-yves, I’d like to grab a 30 minute VC to get a summary of your thoughts on this, since I know you’ve spent a lot of time on this, assuming you can make time Friday (the 21st).) > On Apr 20, 2017, at 7:37 PM, Sean Farley wrote: > >>> In my example above, once "hg undo" is upstreamed, we are able to build >>> a variant without hash preservation[1] and ship that the user by default >>> without delay. >> >> I'm sure you don't mean it this way, but this sounds a lot like "let's >> ship my thing and we'll figure your thing out later". The moment evolve >> ships, it becomes a lot harder to make the types of changes I'm talking >> about (both from a user experience point of view and community >> momentum), so I'd rather have the discussion now while it's still >> possible to make important changes. If we flipped the sentence around >> (ship mine, figure yours out later) I'm sure you wouldn't be happy with >> that outcome either. > > For what it's worth, I did not read it that way. Also, I've tried to > avoid this discussion (across all the various threads) because it has > been draining. > >>> On a general principle, decoupling implementation discussion from UI >>> polishing is usually a win. >> >> If we decoupled UI from implementation here, we'd just go ahead and ship >> "hg unhide" with hash preservation, since that's objectively the more >> intuitive UI for unhide. But since the implementation of the obsolete >> graph doesn't allow that UI, implementation therefore affects our >> discussion. > > At first reading of this, I find this kind of hostile from Facebook. I'm > sure you didn't mean it that way but eh. > > I found it hard to reply to this thread because of all the different > derailings. For every non-Facebook dev here, there are so many more > Facebook devs to reply to. That is exhausting. *I* am exhausted. Looking at the participant list on this message (including me), it’s more non-FB people than FB. That said, all of the following are true: * Facebook is employing a *ton* of people to work on their tooling, including Mercurial * They have a will to upstream some really great work they’ve done to improve the Mercurial user experience, with many hundreds of happy users to back up the utility of their offerings, which means we could be the benefactors of their large group * The community is generally being difficult about these offerings, reducing that will[0] I’m pretty frustrated with how this has gone (both on this thread, and elsewhere). We’ve got *real wins* available, but the conversation has been so fraught and verbose that I have no sense of who wants what. I can be available for video chats most of tomorrow (the 21st, America/New_York "typical waking hours") if that’s of interest and people are willing. Could a couple of people jump in and help me make sense of the state of things (without adding to the book’s worth of email already on this topic). Thanks, Augie (more below as well) 0: It’s not my intent to cast blame. There’s plenty to go around, and I’ll say I’ve not infrequently been a source of difficulty. It’s my belief that we should, as a community, do better at taking advantage of the large user bases that are offering us pre-tested innovative ideas, with contributions of engineering time to land complicated work in core. Every monster thread like this one reduces *everyone’s* willingness to participate in the community, including my own. > I'd love to discuss the pro's and con's of these two ideas purely from a >> UX standpoint, but I haven't seen any concrete examples of situations >> where evolve is affected by this for us to have a tangible discussion >> around it. If we had a concrete example, we could more productively >> evaluate the pro's and con's of these ideas. > > There's so much convolution in this thread. For instance, I think (fast) > local hiding would be cool. A version of that is possible today and I've > even had my hand at it: > > https://bitbucket.org/seanfarley/hgremotenames/commits/69cda2b8353ab1b108ca120d08eb253941f9ae70?at=hideable > > That's remarkably simple and having a bitmap (or whatever) api would be > good. Yes, I think we’re all agreed on that, and it should preferably land (someone’s time allowing) very soon after the freeze ends so we can experiment with it and roll it back if it’s painful. > I'm surprised there has been so much misinformation and changing > of the goal posts. For instance, > [...] > None of the above, in my mind, requires the unhiding / cycle business. > To me, getting the above points in core first (just making the happy > path working, basically) would be a win. If that's not the goal, then > I'm not really enthused about your proposals. I’m starting to think that the unhiding without changing revision hash is more ergonomically reasonable. But as I said above, I think that decision can wait until later. There are real wins in-hand now,
Re: [PATCH 2 of 2] show: add basic labels to work template
On Thu, Apr 20, 2017 at 10:06 AM, Sean Farley wrote: > Gregory Szorc writes: > > > # HG changeset patch > > # User Gregory Szorc > > # Date 1492539008 25200 > > # Tue Apr 18 11:10:08 2017 -0700 > > # Node ID 7f5f78179f5f6afc0f4bea52aa03f1431e03d3d9 > > # Parent d8d4b4acc68859f90f8759309803b116b67a9371 > > show: add basic labels to work template > > > > `hg show work` is much more usable if output is colored. This patch > > implements coloring via label() in a very hacky way. > > > > In a default Mercurial install, you'll see yellow node labels for all > > phases. Branches and bookmarks use the same formatting as the commit > > message. So this change doesn't help much in a default install. But if > > you have a custom colors defined for these things, output is much more > > readable. > > > > The implementation obviously needs some work. But for a minor change > > on a feature that isn't convered by BC, this seems like a clear win > > for the feature in 4.2. > > Do we add this after the rc now? My guess is no but it does seem nice > for 4.2 (shrug) > I thought I would get these in before 4.2 RC. I guess not. Given the highly experimental nature of show, I'd still like to sneak them in if possible. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
