date:20161024

Re: [PATCH evolve] tests: use curl instead of wget

2016-10-24 Thread Matt Harbison

On Mon, 24 Oct 2016 09:37:27 -0400, Simon Farnsworth   
wrote:



On 24/10/2016 14:32, Pierre-Yves David wrote:



On 10/24/2016 03:26 PM, Simon Farnsworth wrote:

# HG changeset patch
# User Simon Farnsworth 
# Date 1477315431 25200
#  Mon Oct 24 06:23:51 2016 -0700
# Branch stable
# Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e
# Parent  970a4c13ebc320a034bc0aff21e0ef0a84157a92
tests: use curl instead of wget

curl is supplied by default on macOS 10.12, but wget isn't. As curl is
easy
to install on other OSes, just switch the tests over.


Hum, 4e7da688a066 and 3ffa12edc05a who did the exact opposite 1.5 year
ago. Can you have a look at them and come back with a plan that fits
both need?



I've looked at the commits you referenced, and there's not enough  
context for me to understand why Matt switched from cURL (works on Linux  
and macOS by default, needs a package installed on Windows as far as I  
understand it), to wget (needs a package installed on Windows and macOS  
as far as I understand it).


Can you give me context for why you took these two commits?


I didn't get a chance to see if wget was installed on previous versions of  
OS X before leaving work today, but I don't recall ever having installed  
it on 10.6 or 10.10.  So maybe that's something new with 10.12?


The reason I switched was because wget is available with msys, but curl  
isn't.  I dug up some Windows build of curl a few months ago, but don't  
recall where.  Maybe it's still in my browser history at work.  I seem to  
have a /mingw/bin/curl on my home system, and vaguely remember building  
that from source a long time ago.


Since I doubt many (any?) people run the tests on Windows, I don't have a  
problem with switching back, if how to install curl is documented on the  
page describing how to run tests on Windows.  I forget if I made similar  
changes in core Mercurial.

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

Re: [PATCH remotefilelog-ext] fileserverclient: avoid ever requesting nullid nodes

2016-10-24 Thread Augie Fackler


> On Oct 24, 2016, at 19:06, Jun Wu  wrote:
> 
> Other than "len(nullids)", the patch looks good to me. I think we can fix it
> in flight.
> 
> Excerpts from Augie Fackler's message of 2016-10-24 18:44:31 -0400:
>> # HG changeset patch
>> # User Augie Fackler 
>> # Date 1477347305 14400
>> #  Mon Oct 24 18:15:05 2016 -0400
>> # Node ID c282b94ef20c036ac6d68eca5ce07077eb61fcb9
>> # Parent  be571104d9f7292cd218dbb1aaebda9ac0b6315f
>> fileserverclient: avoid ever requesting nullid nodes
>> 
>> I keep tripping over bugs where this angers some part of our
>> stack. It's dumb to even be fetching these, but it's harmless to skip
>> them, so issue a developer warning when we encounter one and refuse to
>> fetch it.
>> 
>> diff --git a/remotefilelog/fileserverclient.py 
>> b/remotefilelog/fileserverclient.py
>> --- a/remotefilelog/fileserverclient.py
>> +++ b/remotefilelog/fileserverclient.py
>> @@ -577,6 +577,15 @@ class fileserverclient(object):
>> if fetchhistory:
>> missingids.update(historystore.getmissing(idstocheck))
>> 
>> +# partition missing nodes into nullid and not-nullid so we can
>> +# warn about this filtering potentially shadowing bugs.
>> +nullids = len([None for unused, id in missingids if id == 
>> node.nullid])
>> +if nullids:
>> +missingids = [(f, id) for f, id in missingids if id != 
>> node.nullid]
>> +repo.ui.develwarn(
>> +('remotefilelog not fetching %d null revs'
>> + ' - this is likely hiding bugs' % len(nullids)),
>  
> probably just "null ids"

Ugh, yep, good catch. I'll mail a v2 for ease of application.

>> +config='remotefilelog-ext')
>> if missingids:
>> global fetches, fetched, fetchcost
>> fetches += 1

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

Re: [PATCH V5] update: warn if cwd was deleted

2016-10-24 Thread Danek Duvall

Stanislau Hlebik wrote:

> diff --git a/tests/test-rebase-scenario-global.t 
> b/tests/test-rebase-scenario-global.t
> --- a/tests/test-rebase-scenario-global.t
> +++ b/tests/test-rebase-scenario-global.t
> @@ -758,6 +758,8 @@
>$ hg commit -m 'second source with subdir'
>$ hg rebase -b . -d 1 --traceback
>rebasing 2:779a07b1b7a0 "first source commit"
> +  current directory was removed
> +  (consider changing to repo root: $TESTTMP/cwd-vanish)
>rebasing 3:a7d6f3a00bf3 "second source with subdir" (tip)
>saved backup bundle to 
> $TESTTMP/cwd-vanish/.hg/strip-backup/779a07b1b7a0-853e0073-backup.hg (glob)
>  
> diff --git a/tests/test-update-names.t b/tests/test-update-names.t
> --- a/tests/test-update-names.t
> +++ b/tests/test-update-names.t
> @@ -72,3 +72,15 @@
>$ cd ..
>  
>  #endif
> +
> +Test that warning is printed if cwd is deleted during update
> +  $ hg init r4 && cd r4
> +  $ mkdir dir
> +  $ cd dir
> +  $ echo a > a
> +  $ echo b > b
> +  $ hg add a b
> +  $ hg ci -m "file and dir"
> +  $ hg up -q null
> +  current directory was removed
> +  (consider changing to repo root: $TESTTMP/r1/r4)

So these tests are causing problems on Solaris.  Our rmdir() returns EINVAL
when trying to remove the cwd, even if you're not specifically trying to
remove "." (at least on ZFS).  That error is caught silently handled
elsewhere, though it does leave the directory behind once the command is
complete.  But it does mean that when we get to the getcwd(), the directory
is still there, so the error doesn't happen.

I'm not entirely sure what to do here.  I'm also not really sure what the
driver for this fix was, so I'm not sure if suggesting something like
dropping the warning in favor of silently chdir()ing to the repo root would
be sufficient.

Thoughts?

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

Re: [PATCH] match: adding non-recursive directory matching

2016-10-24 Thread Rodrigo Damazio via Mercurial-devel

It sounds like we'd like to do 3 somewhat orthogonal things:
- allow user to specify the directory the pattern is relative to
(root/cwd/any)
- allow the user to specify recursiveness/non-recursiveness consistently
(not covered by the *path patterns, but could be the defined behavior for
the globs)
- clean up the matcher API (discussed during Sprint)

Doing all 3 together would probably take some time and a lot of
back-and-forth, so I'm wondering if it'd be ok to start by updating this
patch to implement "rootglob" with consistent recursiveness behavior, and
we can then more slowly add the other patterns and converge on a cleaner
API?

Also, for discussion: I assume the *path patterns will be recursive when
they reference a directory. Do we also want a non-recursive equivalent
(rootexact, rootfiles, rootnonrecursive or something like that)?

Thanks
Rodrigo



On Mon, Oct 24, 2016 at 6:21 AM, Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:

>
>
> On 10/21/2016 05:13 PM, FUJIWARA Katsunori wrote:
>
>> At Tue, 18 Oct 2016 10:12:07 -0400,
>> Augie Fackler wrote:
>>
>>>
>>> On Tue, Oct 18, 2016 at 9:52 AM, Yuya Nishihara  wrote:
>>>
 On Tue, 18 Oct 2016 09:40:36 -0400, Augie Fackler wrote:

> On Oct 18, 2016, at 09:38, Yuya Nishihara  wrote:
>>
>>> After coordinating on irc to figure out what this proposal actually
>>> is, I've noticed that the semantics of this "exact" proposal are
>>> exactly what "glob" does today, which means (I think) that
>>> "files:foo/bar" should be representable as "glob:foo/bar/*" - what am
>>> I missing?
>>>
>>
>> Maybe we want a "glob" relative to the repo root?
>>
>
> As far as I can tell, it already is. "relglob:" is relative to your
> location in the repo according to the docs.
>

 Unfortunately that isn't.

 'glob:' - a glob relative to cwd
 'relglob:' - an unrooted glob (*.c matches C files in all
 dirs)

 Don't ask me why. ;-)

>>>
>>> Oh wat. It looks like narrowhg might change this behavior in narrowed
>>> repositories, thus my additional confusion.
>>>
>>> Maybe we should add "absglob" that is always repo-root-absolute. How
>>> do we feel about that overall?
>>>
>>
>> FYI, current pattern matching is implemented as below. This was
>> chatted in "non-recursive directory matching" session of 4.0 sprint,
>> and sorry for my late posting of this translation from
>> http://d.hatena.ne.jp/flying-foozy/20140107/1389087728 in Japanese, as
>> my backlog of the last sprint.
>>
>>    === === ===
>>   pattern type root-ed cwd-ed  any-of-path
>>    === === ===
>>   wildcard --- globrelglob
>>   regexp   re  --- relre
>>   raw string   pathrelpath ---
>>    === === ===
>>
>>   If rule is read in from file (e.g. .hgignore):
>>
>> * "glob" is treated as "relglob"
>> * "re" is treated as "relre"
>>
>>   This is mentioned in "hg help patterns" and "hg help hgignore", but
>>   syntax name "relglob" and "relre" themselves aren't explained.
>>
>>   "end of name" matching is required:
>>
>> * for glob/relglob as PATTERN (e.g. argument in command line), but
>> * not for glob/relglob as INCLUDES/EXCLUDES, or other pattern syntaxes
>>
>>   For example, file "foo/bar/baz" is:
>>
>> * not matched at "hg files glob:foo/bar"
>> * but matched at "hg file -I glob:foo/bar"
>>
>>   This isn't mentioned in any help document :-<, and the latter seems
>>   to cause the issue mentioned in this patch series.
>>
>> How about introducing new systematic names like below to re-organize
>> current complicated mapping between names and matching ? (and enable
>> "end of name" matching by "-eon" suffix or so)
>>
>>     === ===
>>   pattern type root-ed  cwd-ed  any-of-path
>>     === ===
>>   wildcard rootglob cwdglob anyglob
>>   regexp   rootre   cwdre   anyre
>>   raw string   rootpath cwdpath anypath
>>     === ===
>>
>
> Moving toward a more regular and clear feature set and naming seems a win.
> I'm +1 for moving in that direction.
>
> Cheers,
>
> --
> Pierre-Yves David
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

2016-10-24 Thread Barry Scott

FYI: My code that uses this patch is in SCM Workbench.

Here is the code I use for init() and clone():

https://github.com/barry-scott/scm-workbench/blob/master/Source/Hg/
wb_hg_project.py#L65

Here is the object that handles the call back interface and map into my GUI's 
world:

https://github.com/barry-scott/scm-workbench/blob/master/Source/Hg/
wb_hg_project.py#L448

Barry

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

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

2016-10-24 Thread Barry Scott

On Monday, 24 October 2016 22:30:08 BST Yuya Nishihara wrote:
> On Mon, 24 Oct 2016 11:04:39 +0100, Barry Scott wrote:
> > > So this patch contains 3 different things. Can you send them as separate
> > > patches?
> > > 
> > > - add callbacks
> > > - change clone() behavior (which seems wrong)
> > > - add init()
> > 
> > Yes and no. Both clone and init cannot be used with the call backs with
> > these changes.
> > 
> > I can package as 3 patches that build on each other. But in my mind these
> > are linked.
> > 
> > I will do as you advise, please confirm 3 patches required.
> 
> https://www.mercurial-scm.org/wiki/ContributingChanges#Submission_checklist
> 
> "6. patch does just one thing (if you need a bullet list, split your patch)"
> 
> I would split clone/init changes since they solve separate issues on top of
> the new callback API.
> 
> > >> +def setcbprompt(self, cbprompt):
> > >> +"""
> > >> +cbprompt is used to reply to prompts by the server
> > >> + It receives the max number of bytes to return and the
> > >> + contents of stdout received so far.
> > >> +
> > >> +Call with None to stop getting call backs.
> > >> +
> > >> +cbprompt is never called from merge() or import_()
> > >> +which already handle the prompt.
> > >> +"""
> > >> +self._cbprompt = cbprompt
> > > 
> > > Nit: The "cb" prefix doesn't make sense here because there's little
> > > possibility of name conflicts.
> > 
> > True but it is descriptive.
> 
> Hmm, but it introduces new naming style, right? I have no strong opinion
> about this, but "prompt" seems just fine because we already have one.

prompt is not part of the public API.

> 
> > > And I think your setprotocoltrace() covers setcbout/err. Do we still
> > > need them?> 
> > They solve two distinct problems.
> > 
> > protocol tracing provides a way to see the low level, almost unprocessed
> > messages between client and server. Its purpose is to allow inspection
> > and debugging of the protocol.
> > 
> > cbout and cderr provide a user of hglib with the post processed output and
> > error information.
> > 
> > In production my GUI will use cdout and cderr often, but never protocol
> > trace. But when I cannot figure out what is happening I turn on protocol
> > trace to get an insight into how hglib works. That is, for example, how I
> > found that password: is sent on the ‘e’ channel.
> > 
> > Conclusion yes we need both.
> 
> Okay, I don't think they are required, but I agree they are semantically
> different from setprotocoltrace().
> 
> Another option is to provide an interface to set a single callback object
> that handles o/e/I/L channels altogether, so we could provide a helper class
> to translate o+L and e+L sequences to .prompt() and .password()
> respectively.

I've assumed that its better to leave the hglib patch simple.

As we talked about before a getcredentials call back would be great.
But That needs hg itself to change. I sugest that we stay with this API
until that is possible.

> 
> TortoiseHg handles user interaction in that way:
> https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/hgqt/cmdcore.py#cm
> dcore.py-44
> 
> BTW, is hglib usable in GUI? I think its synchronous I/O will behave pretty
> bad in GUI environment.

With these patches its usable :-)

I run any long running hg operation in a background thread.

> > >> def clone(self, source=b('.'), dest=None, branch=None,
> > >> updaterev=None,
> > >> 
> > >> -  revrange=None):
> > >> +  revrange=None, pull=False, uncompressed=False, ssh=None,
> > >> 
> > >> +  remotecmd=None, insecure=False, encoding=None, 
configs=None):
> > >> """
> > >> Create a copy of an existing repository specified by source in
> > >> a new
> > >> directory dest.
> > >> 
> > >> @@ -536,9 +584,30 @@
> > >> 
> > >> revrange - include the specified changeset
> > >> """
> > >> args = cmdbuilder(b('clone'), source, dest, b=branch,
> > >> 
> > >> -  u=updaterev, r=revrange)
> > >> +  u=updaterev, r=revrange, pull=pull,
> > >> +  uncompresses=uncompressed, e=ssh,
> > >> +  remotecmd=remotecmd, insecure=insecure)
> > >> 
> > >> self.rawcommand(args)
> > >> 
> > >> +if self._path is None:
> > >> +self._path = dest
> > >> +# become the client for the cloned hg repo
> > >> +self.close()
> > >> +self._args += ['-R', dest]
> > >> +self.open()
> > > 
> > > This changes the behavior of clone(), but hglib should provide a stable
> > > API.> 
> > It is a backward compatible extension of the API by adding what hglib
> > provided in the __init__.py version of clone.
> 
> No.
> 
>   client = hglib.open()
>   client.root()
>   client.clone('.', 'somewhere')
>   client.root()
> 
> Here clone() shouldn't

Re: [PATCH evolve] tests: use curl instead of wget

2016-10-24 Thread Simon Farnsworth


On 24/10/2016 14:32, Pierre-Yves David wrote:



On 10/24/2016 03:26 PM, Simon Farnsworth wrote:

# HG changeset patch
# User Simon Farnsworth 
# Date 1477315431 25200
#  Mon Oct 24 06:23:51 2016 -0700
# Branch stable
# Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e
# Parent  970a4c13ebc320a034bc0aff21e0ef0a84157a92
tests: use curl instead of wget

curl is supplied by default on macOS 10.12, but wget isn't. As curl is
easy
to install on other OSes, just switch the tests over.


Hum, 4e7da688a066 and 3ffa12edc05a who did the exact opposite 1.5 year
ago. Can you have a look at them and come back with a plan that fits
both need?



I've looked at the commits you referenced, and there's not enough 
context for me to understand why Matt switched from cURL (works on Linux 
and macOS by default, needs a package installed on Windows as far as I 
understand it), to wget (needs a package installed on Windows and macOS 
as far as I understand it).


Can you give me context for why you took these two commits?




diff --git a/tests/test-simple4server-bundle2.t
b/tests/test-simple4server-bundle2.t
--- a/tests/test-simple4server-bundle2.t
+++ b/tests/test-simple4server-bundle2.t
@@ -71,12 +71,12 @@
 Capacity testing
 ===

-  $ wget -q -O -
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=DesF8_W89UXCaJo3gHu4hF5AQTlgK8eV_wP-UyTEsns=
+  $ curl -s
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=DesF8_W89UXCaJo3gHu4hF5AQTlgK8eV_wP-UyTEsns=
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O -
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dcapabilities=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=FvjM7sVt9NyPcthiIFzLTjIbezUtsP4Di9PpsfBwVAk=
+  $ curl -s
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dcapabilities=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=FvjM7sVt9NyPcthiIFzLTjIbezUtsP4Di9PpsfBwVAk=
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon
(no-eol) (glob)

-  $ wget -q -O -
"https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=8DDabWdNhDRmKdDCh432QwB_9SEAzDiTb3D0cgeDTZo=
" | sort
+  $ curl -s
"https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=8DDabWdNhDRmKdDCh432QwB_9SEAzDiTb3D0cgeDTZo=
" | sort
   bookmarks
   namespaces
   obsolete
@@ -128,14 +128,14 @@
 ===
 (used by bitbucket to select which repo use evolve)

-  $ wget -q -O -
"https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=8DDabWdNhDRmKdDCh432QwB_9SEAzDiTb3D0cgeDTZo=
" | sort
+  $ curl -s
"https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dlistkeys-26namespace-3Dnamespaces=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=8DDabWdNhDRmKdDCh432QwB_9SEAzDiTb3D0cgeDTZo=
" | sort
   bookmarks
   namespaces
   obsolete
   phases
-  $ wget -q -O -
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=DesF8_W89UXCaJo3gHu4hF5AQTlgK8eV_wP-UyTEsns=
+  $ curl -s
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dhello=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=DesF8_W89UXCaJo3gHu4hF5AQTlgK8eV_wP-UyTEsns=
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O -
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A-24HGPORT_-3Fcmd-3Dcapabilities=DQICaQ=5VD0RTtNlTh3ycd41b3MUw=mEgSWILcY4c4W3zjApBQLA=TRqRXJPnl1Xu5WCYWcngUdPHt38RiF9mKDvzm0QciU8=FvjM7sVt9NyPcthiIFzLTjIbezUtsP4Di9PpsfBwVAk=
+  $ curl -s

Re: [PATCH evolve] tests: use curl instead of wget

2016-10-24 Thread Pierre-Yves David




On 10/24/2016 03:26 PM, Simon Farnsworth wrote:

# HG changeset patch
# User Simon Farnsworth 
# Date 1477315431 25200
#  Mon Oct 24 06:23:51 2016 -0700
# Branch stable
# Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e
# Parent  970a4c13ebc320a034bc0aff21e0ef0a84157a92
tests: use curl instead of wget

curl is supplied by default on macOS 10.12, but wget isn't. As curl is easy
to install on other OSes, just switch the tests over.


Hum, 4e7da688a066 and 3ffa12edc05a who did the exact opposite 1.5 year 
ago. Can you have a look at them and come back with a plan that fits 
both need?


Thanks.


diff --git a/tests/test-simple4server-bundle2.t 
b/tests/test-simple4server-bundle2.t
--- a/tests/test-simple4server-bundle2.t
+++ b/tests/test-simple4server-bundle2.t
@@ -71,12 +71,12 @@
 Capacity testing
 ===

-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)

-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
@@ -128,14 +128,14 @@
 ===
 (used by bitbucket to select which repo use evolve)

-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
   phases   
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)

   $ echo '[__temporary__]' >> server/.hg/hgrc
@@ -144,7 +144,7 @@
   $ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A access.log 
-E errors.log
   $ cat hg.pid >> $DAEMON_PIDS

-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   phases   
@@ -154,13 +154,13 @@
   $ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A access.log 
-E errors.log
   $ cat hg.pid >> $DAEMON_PIDS

-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
   phases   

-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)
diff --git a/tests/test-simple4server.t b/tests/test-simple4server.t
--- a/tests/test-simple4server.t
+++ b/tests/test-simple4server.t
@@ -73,12 +73,12 @@
 Capacity testing
 ===

-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)

-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
@@ -131,14 +131,14 @@
 ===
 (used by bitbucket to select which repo use evolve)

-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
   phases   
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

2016-10-24 Thread Yuya Nishihara

On Mon, 24 Oct 2016 11:04:39 +0100, Barry Scott wrote:
> > So this patch contains 3 different things. Can you send them as separate
> > patches?
> > 
> > - add callbacks
> > - change clone() behavior (which seems wrong)
> > - add init()
> 
> Yes and no. Both clone and init cannot be used with the call backs with these 
> changes.
> 
> I can package as 3 patches that build on each other. But in my mind these are 
> linked.
> 
> I will do as you advise, please confirm 3 patches required.

https://www.mercurial-scm.org/wiki/ContributingChanges#Submission_checklist

"6. patch does just one thing (if you need a bullet list, split your patch)"

I would split clone/init changes since they solve separate issues on top of
the new callback API.

> >> +def setcbprompt(self, cbprompt):
> >> +"""
> >> +cbprompt is used to reply to prompts by the server
> >> + It receives the max number of bytes to return and the
> >> + contents of stdout received so far.
> >> +
> >> +Call with None to stop getting call backs.
> >> +
> >> +cbprompt is never called from merge() or import_()
> >> +which already handle the prompt.
> >> +"""
> >> +self._cbprompt = cbprompt
> > 
> > Nit: The "cb" prefix doesn't make sense here because there's little 
> > possibility
> > of name conflicts.
> 
> True but it is descriptive.

Hmm, but it introduces new naming style, right? I have no strong opinion about
this, but "prompt" seems just fine because we already have one.

> > And I think your setprotocoltrace() covers setcbout/err. Do we still need 
> > them?
> 
> They solve two distinct problems.
> 
> protocol tracing provides a way to see the low level, almost unprocessed 
> messages between client and server.
> Its purpose is to allow inspection and debugging of the protocol.
> 
> cbout and cderr provide a user of hglib with the post processed output and 
> error information.
> 
> In production my GUI will use cdout and cderr often, but never protocol 
> trace. But when I cannot
> figure out what is happening I turn on protocol trace to get an insight into 
> how hglib works.
> That is, for example, how I found that password: is sent on the ‘e’ channel.
> 
> Conclusion yes we need both.

Okay, I don't think they are required, but I agree they are semantically
different from setprotocoltrace().

Another option is to provide an interface to set a single callback object
that handles o/e/I/L channels altogether, so we could provide a helper class
to translate o+L and e+L sequences to .prompt() and .password() respectively.

TortoiseHg handles user interaction in that way:
https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/hgqt/cmdcore.py#cmdcore.py-44

BTW, is hglib usable in GUI? I think its synchronous I/O will behave pretty
bad in GUI environment.

> >> def clone(self, source=b('.'), dest=None, branch=None, updaterev=None,
> >> -  revrange=None):
> >> +  revrange=None, pull=False, uncompressed=False, ssh=None,
> >> +  remotecmd=None, insecure=False, encoding=None, 
> >> configs=None):
> >> """
> >> Create a copy of an existing repository specified by source in a 
> >> new
> >> directory dest.
> >> @@ -536,9 +584,30 @@
> >> revrange - include the specified changeset
> >> """
> >> args = cmdbuilder(b('clone'), source, dest, b=branch,
> >> -  u=updaterev, r=revrange)
> >> +  u=updaterev, r=revrange, pull=pull,
> >> +  uncompresses=uncompressed, e=ssh,
> >> +  remotecmd=remotecmd, insecure=insecure)
> >> self.rawcommand(args)
> >> 
> >> +if self._path is None:
> >> +self._path = dest
> >> +# become the client for the cloned hg repo
> >> +self.close()
> >> +self._args += ['-R', dest]
> >> +self.open()
> > 
> > This changes the behavior of clone(), but hglib should provide a stable API.
> 
> It is a backward compatible extension of the API by adding what hglib 
> provided in the __init__.py
> version of clone.

No.

  client = hglib.open()
  client.root()
  client.clone('.', 'somewhere')
  client.root()

Here clone() shouldn't reopen the client. Be aware that hglib.open() opens the
repository found in cwd by default.

Maybe you can get some errors by running the test.

  $ python test.py --with-doctest --with-hg path/to/hg

> > Also, dest may be a remote (ssh) path.
> 
> I do not see how my patch breaks things in that case. I do not assume the
> dest is a local path.

If dest isn't a local path, open() with ['-R', dest] would fail.

> >> +def init(self, dest, ssh=None, remotecmd=None, insecure=False,
> >> + encoding=None, configs=None):
> >> +args = util.cmdbuilder(b'init', dest, e=ssh, remotecmd=remotecmd,
> >> +   insecure=insecure)
> >> +

[PATCH evolve] tests: use curl instead of wget

2016-10-24 Thread Simon Farnsworth

# HG changeset patch
# User Simon Farnsworth 
# Date 1477315431 25200
#  Mon Oct 24 06:23:51 2016 -0700
# Branch stable
# Node ID 5fbaca977cd43dfd806a3f452543ef0ed4a4732e
# Parent  970a4c13ebc320a034bc0aff21e0ef0a84157a92
tests: use curl instead of wget

curl is supplied by default on macOS 10.12, but wget isn't. As curl is easy
to install on other OSes, just switch the tests over.

diff --git a/tests/test-simple4server-bundle2.t 
b/tests/test-simple4server-bundle2.t
--- a/tests/test-simple4server-bundle2.t
+++ b/tests/test-simple4server-bundle2.t
@@ -71,12 +71,12 @@
 Capacity testing
 ===
 
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)
 
-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
@@ -128,14 +128,14 @@
 ===
 (used by bitbucket to select which repo use evolve)
 
-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
   phases   
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)
 
   $ echo '[__temporary__]' >> server/.hg/hgrc
@@ -144,7 +144,7 @@
   $ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A access.log 
-E errors.log
   $ cat hg.pid >> $DAEMON_PIDS
 
-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   phases   
@@ -154,13 +154,13 @@
   $ hg serve -R server -n test -p $HGPORT -d --pid-file=hg.pid -A access.log 
-E errors.log
   $ cat hg.pid >> $DAEMON_PIDS
 
-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
   phases   
 
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)
diff --git a/tests/test-simple4server.t b/tests/test-simple4server.t
--- a/tests/test-simple4server.t
+++ b/tests/test-simple4server.t
@@ -73,12 +73,12 @@
 Capacity testing
 ===
 
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s http://localhost:$HGPORT/?cmd=capabilities
   * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 _evoext_obshash_0 
_evoext_obshash_1 _evoext_getbundle_obscommon (no-eol) (glob)
 
-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
@@ -131,14 +131,14 @@
 ===
 (used by bitbucket to select which repo use evolve)
 
-  $ wget -q -O - "http://localhost:$HGPORT/?cmd=listkeys=namespaces; 
| sort
+  $ curl -s "http://localhost:$HGPORT/?cmd=listkeys=namespaces; | 
sort
   bookmarks
   namespaces   
   obsolete 
   phases   
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=hello
+  $ curl -s http://localhost:$HGPORT/?cmd=hello
   capabilities: * _evoext_pushobsmarkers_0 _evoext_pullobsmarkers_0 
_evoext_obshash_0 _evoext_obshash_1 _evoext_getbundle_obscommon (glob)
-  $ wget -q -O - http://localhost:$HGPORT/?cmd=capabilities
+  $ curl -s

Re: [PATCH] match: adding non-recursive directory matching

2016-10-24 Thread Pierre-Yves David




On 10/22/2016 11:35 AM, Yuya Nishihara wrote:

On Thu, 20 Oct 2016 09:19:24 -0700, Rodrigo Damazio wrote:

The issue is that glob:foo/* is recursive in some cases - e.g. "hg files -I
glob:contrib/*" in the hg repo gives me subdirectories of contrib
recursively (including e.g. contrib/docker/apache-server, two levels down).
After discussing a bit more offline with Martin: I'll check if that's a bug
in the matcher's visitdir (rather than a design limitation of glob) before
following up on this change.


It appears -I designed to include subdirectories.

https://selenic.com/repo/hg/file/3.9.2/mercurial/match.py#l135


So the solution to Rodrigo usecase would be a "--include-exact" flag?

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

Re: [PATCH 1 of 2] templater: do not use index.partialmatch() directly to calculate shortest()

2016-10-24 Thread Yuya Nishihara

On Sun, 23 Oct 2016 12:52:34 -0700, Martin von Zweigbergk wrote:
> On Sat, Oct 22, 2016 at 11:35 PM, Yuya Nishihara  wrote:
> > # HG changeset patch
> > # User Yuya Nishihara 
> > # Date 1477199123 -32400
> > #  Sun Oct 23 14:05:23 2016 +0900
> > # Branch stable
> > # Node ID f180a39d749aeacb72936e629a372623b1f88b8c
> > # Parent  76c57e1fe79b0980b377b4f305635dea393d6315
> > templater: do not use index.partialmatch() directly to calculate shortest()
> >
> > cl.index.partialmatch() isn't a drop-in replacement for cl._partialmatch().
> > It has no knowledge about hidden revisions, and it can't accept a node 
> > shorter
> > than the length 4. Instead, let cl._partialmatch() use index.partialmatch()
> > if available.
> >
> > The test result is sampled with --pure.
> >
> > diff --git a/mercurial/templater.py b/mercurial/templater.py
> > --- a/mercurial/templater.py
> > +++ b/mercurial/templater.py
> > @@ -840,13 +840,8 @@ def shortest(context, mapping, args):
> >  cl = mapping['ctx']._repo.changelog
> >  def isvalid(test):
> >  try:
> > -try:
> > -cl.index.partialmatch(test)
> 
> Are there other callers of this method (index.partialmatch) or can we
> remove it now?

It's the low-level function behind cl._partialmatch(), so can't be removed.

> > -except AttributeError:
> > -# Pure mercurial doesn't support partialmatch on the index.
> > -# Fallback to the slow way.
> > -if cl._partialmatch(test) is None:
> > -return False
> > +if cl._partialmatch(test) is None:
> > +return False
> 
> How much slower is it? Correctness is almost always more important,
> but it would be good to know how much slower we're making it.

Here's some numbers. The performance characteristics is identical if no hidden
revision is involved. If there are hidden revisions, _partialmatch() can fall
back to O(len(repo)) path, which means shortest() becomes way slower if
len(shortest(node)) > minlength.

(with no hidden revision)
% hg log -R mozilla-central -r0:2 -T '{node|shortest}\n' --time > /dev/null
(before) time: real 1.310 secs (user 1.290+0.000 sys 0.010+0.000)
(after)  time: real 1.540 secs (user 1.520+0.000 sys 0.020+0.000)

(with hidden revisions)
% hg log -R hg-committed -r0:2 -T '{node|shortest}\n' --time > /dev/null
(before) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000)
(after)  time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000)

If we want to choose the speed over the correctness, we can switch to use the
unfiltered changelog, which will give the same results on both pure and CPy
environments.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH STABLE v2] sslutil: guard against broken certifi installations (issue5406)

2016-10-24 Thread Gábor Stefanik

# HG changeset patch
# User Gábor Stefanik 
# Date 1476893174 -7200
#  Wed Oct 19 18:06:14 2016 +0200
# Branch stable
# Node ID c3fe0e56546a44a7961354d4840cdcb82cbecefc
# Parent  76c57e1fe79b0980b377b4f305635dea393d6315
sslutil: guard against broken certifi installations (issue5406)

Certifi is currently incompatible with py2exe; the Python code for certifi gets
included in library.zip, but not the cacert.pem file - and even if it were
included, SSLContext can't load a cacert.pem file from library.zip.
This currently makes it impossible to build a standalone Windows version of
Mercurial.

Guard against this, and possibly other situations where a module with the name
"certifi" exists, but is not usable.

diff --git a/mercurial/sslutil.py b/mercurial/sslutil.py
--- a/mercurial/sslutil.py
+++ b/mercurial/sslutil.py
@@ -690,14 +690,15 @@
 We don't print a message when the Python is able to load default
 CA certs because this scenario is detected at socket connect time.
 """
-# The "certifi" Python package provides certificates. If it is installed,
-# assume the user intends it to be used and use it.
+# The "certifi" Python package provides certificates. If it is installed
+# and usable, assume the user intends it to be used and use it.
 try:
 import certifi
 certs = certifi.where()
-ui.debug('using ca certificates from certifi\n')
-return certs
-except ImportError:
+if os.path.exists(certs):
+ui.debug('using ca certificates from certifi\n')
+return certs
+except (ImportError, AttributeError):
 pass
 
 # On Windows, only the modern ssl module is capable of loading the system
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH evolve] tests: use curl instead of wget

Re: [PATCH remotefilelog-ext] fileserverclient: avoid ever requesting nullid nodes

Re: [PATCH V5] update: warn if cwd was deleted

Re: [PATCH] match: adding non-recursive directory matching

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

Re: [PATCH evolve] tests: use curl instead of wget

Re: [PATCH evolve] tests: use curl instead of wget

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

[PATCH evolve] tests: use curl instead of wget

Re: [PATCH] match: adding non-recursive directory matching

Re: [PATCH 1 of 2] templater: do not use index.partialmatch() directly to calculate shortest()

[PATCH STABLE v2] sslutil: guard against broken certifi installations (issue5406)

13 matches

Site Navigation

Mail list logo

Footer information