D3212: patch: implement a new worddiff algorithm

[dhduvall (Danek Duvall)]

dhduvall added a comment.


  I can't really tell what's going on there, frankly, unlike with the dim case, 
where it make sense, but I can always change the colors myself.

REPOSITORY
  rHG Mercurial

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

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

D3212: patch: implement a new worddiff algorithm

[dhduvall (Danek Duvall)]

dhduvall added inline comments.

INLINE COMMENTS

> quark wrote in color.py:94
> There are not many choices - dim, 16/256 colors, or bold. We ended up with 
> 16/256 colors internally for wider support (ex. tmux). But I'd like to 
> express my (strong) options that:
> 
> - diff.inserted.changed and diff.inserted are same
> - diff.inserted is not bold
> 
> in this patch. Because color.py has no 16/256 support yet (and if it does 
> detection conservatively, most terminals will only report 8 color support). 
> And the only remaining choice is "dim". For weird terminals like tmux, I 
> think it's their bugs to fix, not this patch.
> 
> That said, I'm fine with changing the defaults to whatever. So feel free to 
> send follow-ups changing it.

I'm not sure what testing I did to claim "most", but I did make that comment in 
2011, and xterm didn't start supporting dim until 2014 (it had long supported 
invisible), so that certainly helped inform that comment. Given @spectral's 
survey, I'd probably rewrite the comment simply to say that we're using 
`ui.debug()` to not be noisy in the wide world of different terminals.

Given support by xterm, iTerm2, and Terminal.app (and I just verified 
gnome-terminal supports it, too), I'd lean towards just using dim whenever it 
made sense now, though it'd be nice to know that at least one major Windows 
terminal app supported it, too. I don't know how widespread rxvt-unicode is in 
the Linux world, or other terminal emulators that might not support it.

I won't comment on the dim-the-unchanged vs bright-the-changed bits, or how 
this interacts with the ANSI color mode, other than to say that the default 
colors aren't an interface, and can be tweaked later without worries about 
backwards compatibility. Obviously you don't want to change them radically 
without good reason once people get used to them, but tweaking 
dim/bold/normal/background/whatever once people have had a chance to experiment 
more widely might be a reasonable thing to do.

REPOSITORY
  rHG Mercurial

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

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

D2391: sshpeer: factor out code for creating peers from pipes

[dhduvall (Danek Duvall)]

dhduvall added inline comments.

INLINE COMMENTS

> sshpeer.py:537
> +
> +``path`` and ``path`` are stored on the eventual peer instance and may
> +not be used for anything meaningful.

That second `path` should be `proc`?

REPOSITORY
  rHG Mercurial

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

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

Re: Accessing hidden commits by hash (directaccess extension)

[Danek Duvall]

This is great.  I've been hitting my head against this ever since I started
using evolve, and I'll be thrilled to have this functionality.

A couple of questions:

  - If a revision range is given that ends (or begins, I suppose) with a
hidden changeset, will any intervening hidden changesets also be
temporarily unhidden?

  - The recoverable-write commands often pop you into an editor before any
warning can be seen and understood.  Should the warning be available in
the editor template?

  - The unrecoverable-write commands could probably stand to explain why
they're preventing the operation from happening, but perhaps more
importantly, if you use --hidden with them, will they actually
push/serve/whatever?  I guess I can see wanting a complete clone of a
repo, including hidden changesets, so pushing them around would make
sense in that context, but I thought we weren't going there.

Along similar lines, I've also wanted the ability to push and pull secret
changesets between (non-publishing) repositories, but only when specificied
by name like this.  Seems like there could be some shared mechanism there,
if it's not just me.

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

Re: D219: morestatus: move fb extension to core by plugging to `hg status --verbose`

[Danek Duvall]

durin42 (Augie Fackler) wrote:

>   I've heard no objections, but also the suggestion that --terse be
> something like --terse-dirs or similar so it's obviously not the antonym
> of --verbose.

Maybe --collapse?  I think that's what you do when you've got a directory
tree in a GUI and you rotate the little triangle thingie, which is pretty
much what --terse does.

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

[PATCH] tests: tell pip not to check for a newer version

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1497994553 25200
#  Tue Jun 20 14:35:53 2017 -0700
# Node ID 657e3a53dff24205ebeaffa72a378103ba8338d5
# Parent  404b6acfa192b630fab3c371da072eb8b713d4c1
tests: tell pip not to check for a newer version

pip will check to see if it's the latest version, and complain if it isn't.
The --no-index flag implies the --disable-pip-version-check flag, and makes
the warning (and any associated network activity) go away.

diff --git a/tests/test-install.t b/tests/test-install.t
--- a/tests/test-install.t
+++ b/tests/test-install.t
@@ -188,7 +188,7 @@ the default for them.
   $ $PYTHON -m virtualenv --no-site-packages --never-download installenv >> 
pip.log
 Note: we use this weird path to run pip and hg to avoid platform differences,
 since it's bin on most platforms but Scripts on Windows.
-  $ ./installenv/*/pip install $TESTDIR/.. >> pip.log
+  $ ./installenv/*/pip install --no-index $TESTDIR/.. >> pip.log
   $ ./installenv/*/hg debuginstall || cat pip.log
   checking encoding (ascii)...
   checking Python executable (*) (glob)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] tests: redirect virtualenv stderr to same file as stdout

[Danek Duvall]

Danek Duvall wrote:

> Augie Fackler wrote:
> 
> > 
> > > On Jun 20, 2017, at 16:53, Augie Fackler <r...@durin42.com> wrote:
> > > 
> > > # HG changeset patch
> > > # User Augie Fackler <au...@google.com>
> > > # Date 1497991974 14400
> > > #  Tue Jun 20 16:52:54 2017 -0400
> > > # Node ID ff3964f237d601e7c375c10fbf93029b5db39307
> > > # Parent  0ce2cbebd74964ffe61e79de8941461bccc9371b
> > > tests: redirect virtualenv stderr to same file as stdout
> > > 
> > > I'm seeing some failures on the Solaris buildbots due to a warning
> > > about an old pip, but I can't reproduce this locally. Hopefully this 
> > > helps.
> > 
> > Specifically, this is for 
> > https://buildbot.mercurial-scm.org/builders/Solaris%2012%20x86%20tests/builds/204/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio
> >  - I think I got it right, but I honestly have no idea. Can you check and 
> > see if this fixes that test on that machine?
> 
> I think the 2>&1 would need to be on the subsequent pip install command,
> but I'll make sure.

Indeed, that's correct.

But assuming that all necessary versions of pip have it, there's also the
--disable-pip-version-check flag, or --no-index, which implies it.  I just
ran a test (as myself, not in the same environment as the tests), and
--no-index makes the message go away, as well as lets the test succeed
without redirecting stderr.

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

Re: [PATCH] tests: redirect virtualenv stderr to same file as stdout

[Danek Duvall]

Augie Fackler wrote:

> 
> > On Jun 20, 2017, at 16:53, Augie Fackler  wrote:
> > 
> > # HG changeset patch
> > # User Augie Fackler 
> > # Date 1497991974 14400
> > #  Tue Jun 20 16:52:54 2017 -0400
> > # Node ID ff3964f237d601e7c375c10fbf93029b5db39307
> > # Parent  0ce2cbebd74964ffe61e79de8941461bccc9371b
> > tests: redirect virtualenv stderr to same file as stdout
> > 
> > I'm seeing some failures on the Solaris buildbots due to a warning
> > about an old pip, but I can't reproduce this locally. Hopefully this helps.
> 
> Specifically, this is for 
> https://buildbot.mercurial-scm.org/builders/Solaris%2012%20x86%20tests/builds/204/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio
>  - I think I got it right, but I honestly have no idea. Can you check and see 
> if this fixes that test on that machine?

I think the 2>&1 would need to be on the subsequent pip install command,
but I'll make sure.

Danek

> Thanks!
> 
> > 
> > diff --git a/tests/test-install.t b/tests/test-install.t
> > --- a/tests/test-install.t
> > +++ b/tests/test-install.t
> > @@ -185,7 +185,7 @@ Note: --no-site-packages is deprecated, 
> > ancient virtualenv from their linux distro or similar and it's not yet
> > the default for them.
> >   $ unset PYTHONPATH
> > -  $ $PYTHON -m virtualenv --no-site-packages --never-download installenv 
> > >> pip.log
> > +  $ $PYTHON -m virtualenv --no-site-packages --never-download installenv 
> > >> pip.log 2>&1
> > Note: we use this weird path to run pip and hg to avoid platform 
> > differences,
> > since it's bin on most platforms but Scripts on Windows.
> >   $ ./installenv/*/pip install $TESTDIR/.. >> pip.log
> > ___
> > 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

[PATCH] tests: don't touch the network when using virtualenv

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1497913700 25200
#  Mon Jun 19 16:08:20 2017 -0700
# Node ID c129491ce55e703b50d39fb30ae6da6aa50fc78e
# Parent  661025fd3e1cd5d5e2dee12b7f64312d6cd48a0b
tests: don't touch the network when using virtualenv

diff --git a/tests/test-install.t b/tests/test-install.t
--- a/tests/test-install.t
+++ b/tests/test-install.t
@@ -185,7 +185,7 @@ Note: --no-site-packages is deprecated, 
 ancient virtualenv from their linux distro or similar and it's not yet
 the default for them.
   $ unset PYTHONPATH
-  $ $PYTHON -m virtualenv --no-site-packages installenv >> pip.log
+  $ $PYTHON -m virtualenv --no-site-packages --never-download installenv >> 
pip.log
 Note: we use this weird path to run pip and hg to avoid platform differences,
 since it's bin on most platforms but Scripts on Windows.
   $ ./installenv/*/pip install $TESTDIR/.. >> pip.log
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3 v2 pip-fix] tests: add a test for installing hg with pip in a virtualenv

[Danek Duvall]

Danek Duvall wrote:

> Augie Fackler wrote:
> 
> > 
> > > On Jun 19, 2017, at 18:13, Donald Stufft <don...@stufft.io> wrote:
> > > 
> > >>> Any thoughts on what to do here?  The ping command has a different
> > >>> interface on Solaris than on Linux, so trying to simply ping
> > >>> pypi.python.org (assuming we can rely on pip always trying that host) is
> > >>> going to run into platform-specific issues.  We could save http_proxy
> > >>> aside, and enable it here specifically (somehow).  Or we could allow for
> > >>> specific "have"s to be blacklisted, and introduce some sort of
> > >>> external-network #if token, maybe?
> > >> 
> > >> I was going to suggest an hghave check that lets us be sure we can see 
> > >> authentic pypi - dstufft, do you have some endpoint that'd be suitable 
> > >> for such a sniff-test?
> > >> 
> > >> (The test in question is an end-to-end setup.py install test that makes 
> > >> a virtualenv, which I think is failing because it wants to slurp down 
> > >> pip and setuptools...)
> > >> 
> > > 
> > > 
> > > You could just tell virtualenv not to pull down the latest 
> > > pip/setuptools/etc? That seems like the best solution here since 
> > > presumably you don’t want your tests hitting the network unless required 
> > > anyways?
> > 
> > That sounds like exactly what I want - do you know how to do that? Is
> > that the --never-download flag which says it does nothing on my Python
> > 2.7.13? (but maybe Danek has an older virtualenv?) 
> 
> We have virtualenv 15.0.1, on S12, and 12.0.7 on 11.3.  Python is 2.7.13
> and 2.7.9, respectively.
> 
> Oddly, --never-download says it's deprecated on 12.0.7, but not on 15.0.1
> (where it's also added the --no-download alias).

And, FWIW, adding --never-download to the invocation allows the test to
succeed for me.

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

Re: [PATCH 3 of 3 v2 pip-fix] tests: add a test for installing hg with pip in a virtualenv

[Danek Duvall]

Donald Stufft wrote:

> 
> > On Jun 19, 2017, at 6:15 PM, Augie Fackler  wrote:
> > 
> > 
> >> On Jun 19, 2017, at 18:13, Donald Stufft  wrote:
> >> 
>  Any thoughts on what to do here?  The ping command has a different
>  interface on Solaris than on Linux, so trying to simply ping
>  pypi.python.org (assuming we can rely on pip always trying that host) is
>  going to run into platform-specific issues.  We could save http_proxy
>  aside, and enable it here specifically (somehow).  Or we could allow for
>  specific "have"s to be blacklisted, and introduce some sort of
>  external-network #if token, maybe?
> >>> 
> >>> I was going to suggest an hghave check that lets us be sure we can see 
> >>> authentic pypi - dstufft, do you have some endpoint that'd be suitable 
> >>> for such a sniff-test?
> >>> 
> >>> (The test in question is an end-to-end setup.py install test that makes a 
> >>> virtualenv, which I think is failing because it wants to slurp down pip 
> >>> and setuptools...)
> >>> 
> >> 
> >> 
> >> You could just tell virtualenv not to pull down the latest 
> >> pip/setuptools/etc? That seems like the best solution here since 
> >> presumably you don’t want your tests hitting the network unless required 
> >> anyways?
> > 
> > That sounds like exactly what I want - do you know how to do that? Is that 
> > the --never-download flag which says it does nothing on my Python 2.7.13? 
> > (but maybe Danek has an older virtualenv?)
> 
> 
> There is.. some history here. Basically if you have an old version of 
> virtualenv —no-download / —never-download will turn off downloading from 
> PyPI… if you have a recent but not super recent version of virtualenv, 
> —no-download / —never-download does nothing (because we ripped out the 
> network code for awhile), then if you have a recent version of virtualenv, 
> —no-download / —never-download disables the new on-by-default code to pull 
> down the latest pip/setuptools/etc.
> 
> So tl;dr; use —no-download.

Why not --never-download, since all versions will understand it?

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

Re: [PATCH 3 of 3 v2 pip-fix] tests: add a test for installing hg with pip in a virtualenv

[Danek Duvall]

Augie Fackler wrote:

> 
> > On Jun 19, 2017, at 18:13, Donald Stufft  wrote:
> > 
> >>> Any thoughts on what to do here?  The ping command has a different
> >>> interface on Solaris than on Linux, so trying to simply ping
> >>> pypi.python.org (assuming we can rely on pip always trying that host) is
> >>> going to run into platform-specific issues.  We could save http_proxy
> >>> aside, and enable it here specifically (somehow).  Or we could allow for
> >>> specific "have"s to be blacklisted, and introduce some sort of
> >>> external-network #if token, maybe?
> >> 
> >> I was going to suggest an hghave check that lets us be sure we can see 
> >> authentic pypi - dstufft, do you have some endpoint that'd be suitable for 
> >> such a sniff-test?
> >> 
> >> (The test in question is an end-to-end setup.py install test that makes a 
> >> virtualenv, which I think is failing because it wants to slurp down pip 
> >> and setuptools...)
> >> 
> > 
> > 
> > You could just tell virtualenv not to pull down the latest 
> > pip/setuptools/etc? That seems like the best solution here since presumably 
> > you don’t want your tests hitting the network unless required anyways?
> 
> That sounds like exactly what I want - do you know how to do that? Is
> that the --never-download flag which says it does nothing on my Python
> 2.7.13? (but maybe Danek has an older virtualenv?) 

We have virtualenv 15.0.1, on S12, and 12.0.7 on 11.3.  Python is 2.7.13
and 2.7.9, respectively.

Oddly, --never-download says it's deprecated on 12.0.7, but not on 15.0.1
(where it's also added the --no-download alias).

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

Re: [PATCH V2] status: add a flag to terse the output (issue4119)

[Danek Duvall]

I'd like to see some text in the help output that talks about -t and its
arguments -- what are they, what do they mean, what it means to combine
them, how to disable them.

Pulkit Goyal wrote:

> @@ -4804,16 +4806,28 @@
>  show = [k for k in states if opts.get(k)]
>  if opts.get('all'):
>  show += ui.quiet and (states[:4] + ['clean']) or states
> +if ui.quiet and terse:
> +for st in ('ignored', 'unknown'):
> +if st[0:1] in terse:
> +show.append(st)
> +
>  if not show:
>  if ui.quiet:
>  show = states[:4]
>  else:
>  show = states[:5]
> +if terse:
> +for st in ('ignored', 'unknown', 'clean'):
> +if st[0:1] in terse:
> +show.append(st)

Is there a reason you're using [0:1] here instead of simply [0]?

> diff --git a/tests/test-terse-status.t b/tests/test-terse-status.t
> new file mode 100644
> --- /dev/null
> +++ b/tests/test-terse-status.t
> @@ -0,0 +1,106 @@
> +  $ mkdir folder
> +  $ cd folder
> +  $ hg init
> +  $ mkdir x
> +  $ touch a b x/aa.o x/bb.o
> +  $ hg status
> +  ? a
> +  ? b
> +  ? x/aa.o
> +  ? x/bb.o
> +
> +Show that only passed status are tersed
> +  $ hg status --terse m
> +  ? a
> +  ? b
> +  ? x/aa.o
> +  ? x/bb.o

I think you need some tests that actually end up tersing a directory that
has only modified (or added, or ...) files.

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

Re: [PATCH 3 of 3 v2 pip-fix] tests: add a test for installing hg with pip in a virtualenv

[Danek Duvall]

I've been running into problems with this.  It's not a Solaris issue, but
because I'm running inside a non-transparent firewall.

http_proxy is being stripped from the environment of each test, but in
order to do a pip install, I need that environment variable in order to
connect outside.

I also need to have virtualenv on the system, so I can't disable the test
by making sure the #if evaluates to false.

I'm not sure why this isn't failing on the buildbot instances, which should
have the same issue.

Any thoughts on what to do here?  The ping command has a different
interface on Solaris than on Linux, so trying to simply ping
pypi.python.org (assuming we can rely on pip always trying that host) is
going to run into platform-specific issues.  We could save http_proxy
aside, and enable it here specifically (somehow).  Or we could allow for
specific "have"s to be blacklisted, and introduce some sort of
external-network #if token, maybe?

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

Re: [PATCH RFC WIP] status: add an option to see terse status (WIP)

[Danek Duvall]

Pulkit Goyal wrote:

> On Sun, May 28, 2017 at 11:30 PM, Augie Fackler  wrote:
> >
> >> On May 26, 2017, at 5:18 PM, Pulkit Goyal <7895pul...@gmail.com> wrote:
> >>
> >> # HG changeset patch
> >> # User Pulkit Goyal <7895pul...@gmail.com>
> >> # Date 1495832891 -19800
> >> #  Sat May 27 02:38:11 2017 +0530
> >> # Node ID 76fb3bdd547259620eec714c0d50fe1f9da25ebf
> >> # Parent  2b5953a49f1407f825d65b45986d213cb5c79203
> >> status: add an option to see terse status (WIP)
> >
> > I’m generally in favor of terse status, but with a quirk: I think it should 
> > only be terse by default for ?, which mirrors the Subversion behavior.
> 
> I was working on this and had a doubt. Shall a folder containing files
> with only unknown and ignored status can be tersed as unknown?

The simple answer to this is yes, if for no other reason than one of the
upsides of terse-status is that it doesn't spend forever descending through
directory hierarchies that have no files managed by mercurial.

If I want to see files there which are ignored, I can always turn off the
terseness, and wait.

Of course, that assumes that the set of ignored files and the set of files
managed by mercurial are exclusive, which they needn't be.  In that case,
I'd probably want to see the ignored files if I simply asked to see ignored
files, even if there were no other managed files in that directory.

So it seems to me that the decision to descend should be made based on
whether there are managed files.

Danek

> An example for this is a folder containing .py and .pyc files from
> which .pyc files are ignored.
> 
> The similar thing applies for modified, and added files. Do we want to
> make all the statuses mutually exclusive to each other while tersing
> OR can some of them exist together and we add the behaviour to use
> --verbose to consider the ignored files. Can we do something else
> also?
> 
> In my opinion the first one will be straightforward for users to
> understand. The later one might result in some confusion.
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] solaris: solaris grep doesn't have -A; reimplement with awk

[Danek Duvall]

Augie Fackler wrote:

> > I'm happy to add the check, though, if folks think it's the right path
> > forward.  I assume that -B and -C should come along for the ride?
> 
> Yep, (I’m assuming since you asked solaris grep is also sad about those 
> flags.)

Solaris grep is sad about many flags.  Except --get-off-my-lawn.

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

Re: [PATCH] solaris: solaris grep doesn't have -A; reimplement with awk

[Danek Duvall]

Pierre-Yves David wrote:

> 
> 
> On 06/03/2017 01:20 AM, danek.duv...@oracle.com wrote:
> ># HG changeset patch
> ># User Danek Duvall <danek.duv...@oracle.com>
> ># Date 1496445527 25200
> >#  Fri Jun 02 16:18:47 2017 -0700
> ># Node ID d41ec8a079648101eae94a25e05c6d7a7b26b653
> ># Parent  e6ff007e107e434b35eb881711f459c7a75c91b2
> >solaris: solaris grep doesn't have -A; reimplement with awk
> 
> We should probably get a check-code rules for this.

Given that there's no consistent replacement for it, I'm a bit uncertain.
Adding a flag to a command makes sense in this case, but maybe not always
in the future.

I'm happy to add the check, though, if folks think it's the right path
forward.  I assume that -B and -C should come along for the ride?

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

[PATCH] debugbundle: add --part-type flag to emit only named part types

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1496704781 25200
#  Mon Jun 05 16:19:41 2017 -0700
# Node ID 67209fdbca98cf2a38b05cb06f093dc376803590
# Parent  e696f597d02f971eeed1217096b8f200ddb903d2
debugbundle: add --part-type flag to emit only named part types

This removes the need in the tests for grep -A, which is not supported on
Solaris.

diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
--- a/mercurial/debugcommands.py
+++ b/mercurial/debugcommands.py
@@ -314,7 +314,10 @@ def _debugbundle2(ui, gen, all=None, **o
 if not isinstance(gen, bundle2.unbundle20):
 raise error.Abort(_('not a bundle2 file'))
 ui.write(('Stream params: %s\n' % repr(gen.params)))
+part_types = opts.get('part_type', [])
 for part in gen.iterparts():
+if part_types and part.type not in part_types:
+continue
 ui.write('%s -- %r\n' % (part.type, repr(part.params)))
 if part.type == 'changegroup':
 version = part.params.get('version', '01')
@@ -325,6 +328,7 @@ def _debugbundle2(ui, gen, all=None, **o
 
 @command('debugbundle',
 [('a', 'all', None, _('show all details')),
+ ('', 'part-type', [], _('show only the named part type')),
  ('', 'spec', None, _('print the bundlespec of the bundle'))],
 _('FILE'),
 norepo=True)
diff --git a/tests/test-completion.t b/tests/test-completion.t
--- a/tests/test-completion.t
+++ b/tests/test-completion.t
@@ -247,7 +247,7 @@ Show all commands + options
   debugancestor: 
   debugapplystreamclonebundle: 
   debugbuilddag: mergeable-file, overwritten-file, new-file
-  debugbundle: all, spec
+  debugbundle: all, part-type, spec
   debugcheckstate: 
   debugcolor: style
   debugcommands: 
diff --git a/tests/test-obsolete-bundle-strip.t 
b/tests/test-obsolete-bundle-strip.t
--- a/tests/test-obsolete-bundle-strip.t
+++ b/tests/test-obsolete-bundle-strip.t
@@ -67,7 +67,7 @@ obsmarkers. It also check the obsmarkers
   > cat "${markersfile}"
   > printf "# bundling: "
   > hg bundle --hidden --base "parents(roots(${revs}))" --rev "${revs}" 
"${bundlefile}"
-  > hg debugbundle "${bundlefile}" | grep "obsmarkers --" -A 100 | sed 
1,2d > "${contentfile}"
+  > hg debugbundle --part-type obsmarkers "${bundlefile}" | sed 1,3d > 
"${contentfile}"
   > echo '### Bundled markers ###'
   > cat "${contentfile}"
   > echo '### diff   ###'
@@ -86,7 +86,7 @@ obsmarkers. It also check the obsmarkers
   > hg debugobsolete --hidden | sort | sed 's/^//' > 
"${prestripfile}"
   > hg strip --hidden --rev "${revs}"
   > hg debugobsolete --hidden | sort | sed 's/^//' > 
"${poststripfile}"
-  > hg debugbundle .hg/strip-backup/* | grep "obsmarkers --" -A 100 | 
sed 1,2d > "${stripcontentfile}"
+  > hg debugbundle --part-type obsmarkers .hg/strip-backup/* | sed 
1,3d > "${stripcontentfile}"
   > echo '### Backup markers ###'
   > cat "${stripcontentfile}"
   > echo '### diff   ###'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] solaris: solaris grep doesn't have -A; reimplement with awk

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1496445527 25200
#  Fri Jun 02 16:18:47 2017 -0700
# Node ID d41ec8a079648101eae94a25e05c6d7a7b26b653
# Parent  e6ff007e107e434b35eb881711f459c7a75c91b2
solaris: solaris grep doesn't have -A; reimplement with awk

diff --git a/tests/test-obsolete-bundle-strip.t 
b/tests/test-obsolete-bundle-strip.t
--- a/tests/test-obsolete-bundle-strip.t
+++ b/tests/test-obsolete-bundle-strip.t
@@ -67,7 +67,7 @@ obsmarkers.
   > cat "${markersfile}"
   > printf "# bundling: "
   > hg bundle --hidden --base "parents(roots(${revs}))" --rev "${revs}" 
"${bundlefile}"
-  > hg debugbundle "${bundlefile}" | grep "obsmarkers --" -A 100 | sed 
1,2d > "${contentfile}"
+  > hg debugbundle "${bundlefile}" | awk '/obsmarkers --/ {p=1} p == 1 
{print}' | sed 1,2d > "${contentfile}"
   > echo '### Bundled markers ###'
   > cat "${contentfile}"
   > echo '### diff   ###'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: San Francisco Meetup

[Danek Duvall]

Sean Farley wrote:

> Just a quick followup to my suggestion of a mini hackathon in San
> Francisco (hopefully in a somewhat frequent manner). I was thinking of
> testing it out this Saturday for coffee / brunch:
> 
> https://www.meetup.com/Bay-Area-Mercurial-Meetup/events/239870170/
> 
> It's a free-form thing. Suggestions on locations / time welcomed. If no
> one is interested, that's cool too. I'll be around the city hacking
> anyways :-)

I'm in Boston for the OpenStack conference, so not this time.

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

Re: [PATCH stable] tests: pass only one file at a time to tail(1)

[Danek Duvall]

Augie Fackler wrote:

> # HG changeset patch
> # User Augie Fackler 
> # Date 1492954690 14400
> #  Sun Apr 23 09:38:10 2017 -0400
> # Branch stable
> # Node ID 6db2667e46e8831772e38639088e39932355336e
> # Parent  f82cdd5ee57e468c3801cd340691e9b2497a49b2
> tests: pass only one file at a time to tail(1)
> 
> It looks like the verison on Solaris only tails one file at a time.

Simple solution; I'm sorry it never occurred to me.  Though perhaps "cat"
makes more sense here, since tail actually does grab the whole file?  The
only reason to prefer tail, AFAICT, is for its ability to stick a header
before each file.

Thanks,
Danek

> diff --git a/tests/test-convert-hg-sink.t b/tests/test-convert-hg-sink.t
> --- a/tests/test-convert-hg-sink.t
> +++ b/tests/test-convert-hg-sink.t
> @@ -440,15 +440,12 @@ Two way tests
>$ echo b > b/f
>$ hg -R b ci -mb
>  
> -  $ tail */.hg/shamap
> -  ==> 0/.hg/shamap <==
> +  $ tail 0/.hg/shamap
>86f3f774ffb682bffb5dc3c1d3b3da637cb9a0d6 
> 8a028c7c77f6c7bd6d63bc3f02ca9f779eabf16a
>dd9f218eb91fb857f2a62fe023e1d64a4e7812fe 
> 8a028c7c77f6c7bd6d63bc3f02ca9f779eabf16a
> -  
> -  ==> a/.hg/shamap <==
> +  $ tail a/.hg/shamap
>8a028c7c77f6c7bd6d63bc3f02ca9f779eabf16a 
> 86f3f774ffb682bffb5dc3c1d3b3da637cb9a0d6
> -  
> -  ==> b/.hg/shamap <==
> +  $ tail b/.hg/shamap
>8a028c7c77f6c7bd6d63bc3f02ca9f779eabf16a 
> dd9f218eb91fb857f2a62fe023e1d64a4e7812fe
>  
>$ hg convert a 0
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 6] tests: add tests for poorly behaving HTTP server

[Danek Duvall]

Gregory Szorc wrote:

> +Failure to accept() socket should result in connection related error message
> +
> +  $ hg --config badserver.closebeforeaccept=true serve -p $HGPORT -d 
> --pid-file=hg.pid
> +  $ cat hg.pid > $DAEMON_PIDS
> +
> +  $ hg clone http://localhost:$HGPORT/ clone
> +  abort: error: Connection reset by peer
> +  [255]
> +
> +(The server exits on its own, but there is a race between that and starting 
> a new server.
> +So ensure the process is dead.)
> +
> +  $ killdaemons.py $DAEMON_PIDS
> +
> +Failure immediately after accept() should yield connection related error 
> message
> +
> +  $ hg --config badserver.closeafteraccept=true serve -p $HGPORT -d 
> --pid-file=hg.pid
> +  $ cat hg.pid > $DAEMON_PIDS
> +
> +  $ hg clone http://localhost:$HGPORT/ clone
> +  abort: error: Connection reset by peer
> +  [255]

I'm seeing

  abort: error: ''

for this on Solaris (just the closeafteraccept case).  I've traced it back
to getting a BadStatusLine exception instead of a read (or whatever)
resulting in ECONNRESET:

   Traceback (most recent call last):
 File ".../mercurial/keepalive.py", line 239, in do_open
   r = h.getresponse()
 File ".../mercurial/url.py", line 158, in getresponse
   return keepalive.HTTPConnection.getresponse(self)
 File ".../mercurial/keepalive.py", line 578, in safegetresponse
   return cls.getresponse(self)
 File "/usr/lib/python2.7/httplib.py", line 1121, in getresponse
   response.begin()
 File "/usr/lib/python2.7/httplib.py", line 438, in begin
   version, status, reason = self._read_status()
 File "/usr/lib/python2.7/httplib.py", line 402, in _read_status
   raise BadStatusLine(line)

Any thoughts on this before I spend more time digging?

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

Re: stable ordering of test output

[Danek Duvall]

Augie Fackler wrote:

> On Thu, Apr 13, 2017 at 3:55 PM, Augie Fackler  wrote:
> > On Wed, Mar 8, 2017 at 10:44 AM, Yuya Nishihara  wrote:
> >> On Tue, 7 Mar 2017 17:56:58 +0100, Pierre-Yves David wrote:
> >>> On the other hand, this is probably not so bundle2 specific. We have
> >>> some "select" logic to read stdout and stderr as soon as possible. This
> >>> is the main suspect as it is possible that this logic behave different
> >>> under linux and other unix (not too much effort have been put into it).
> >>
> >> posix.poll() waits every type of operation no matter if fd is e.g. writable
> >> or not. IIRC, this doesn't always work on FreeBSD since the underlying 
> >> resource
> >> of read/write ends might be shared in the kernel.
> >>
> >> But I don't think this is the source of the unstable output.
> >
> > I've had a little time today between things to try and debug this.
> > What I've found so far:
> >
> > 1) when the test passes, the remote: output is printed by the
> > _forwardoutput method in sshpeer, presumably since stderr makes it to
> > the client before the close of stdout.
> > 2) When the test fails (as on BSD, and I guess Solaris), the client
> > notices that stdout closed before stderr. It then aborts the
> > transaction and sshpeer.cleanup() notices some data chilling on stderr
> > and ensures it gets read and printed.
> >
> > I'm not really sure why BSD systems would be quicker at communicating
> > the closed FD than other systems. I'm poking at dummyssh now to see if
> > maybe it's weirdness from there...
> 
> Here's a patch that seems to work. I'm not happy about it, but it
> makes the behavior consistent, and it looks mostly harmless.

Confirmed that it fixes the problem on Solaris, too.

Thanks!

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

Re: [PATCH 3 of 3 V2] url: support auth.cookiefile for adding cookies to HTTP requests

[Danek Duvall]

Gregory Szorc wrote:

> +The following options apply to all hosts.
> +
> +``cookiefile``
> +Path to a file containing HTTP cookie lines. Cookies matching a
> +host will be sent automatically.
> +
> +The file format uses the Mozilla cookies.txt or libwww-perl "Set-Cookie3"
> +format. For specifics of each format, do an Internet search for
> +"Netscape cookies.txt format" or "libwww-perl cookie format."
> +
> +Note: the Mozilla cookies parser does not handle port numbers on domains.
> +You will need to remove ports from the domain for the cookie to be
> +recognized. This could result in a cookie being disclosed to an unwanted
> +server.
> +
> +The cookies file is read-only.

How is the user expected to add cookies to the file?  If the cookie is
regenerated frequently, this could be problematic.  Better than nothing,
perhaps, but still a pain.  Maybe a quick sentence or two on cookie file
management would be useful?

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

Re: hg-git and round-tripping (and file copies?)

[Danek Duvall]

Sean Farley wrote:

> Danek Duvall <danek.duv...@oracle.com> writes:
> 
> > Mike Hommey wrote:
> >
> >> If your goal trying to round-trip between mercurial and git is to
> >> provide developers with the possibility to use mercurial or git as they
> >> like, and somehow make it work with developers pushing on both ends, you
> >> should instead use a single source of truth (mercurial or git, whichever
> >> you prefer keeping a server for), and let developers use conversion tools
> >> on their end. hg-git can be used by developers who prefer mercurial when
> >> the server is git (although it annoyingly adds visible metadata to git
> >> commits in that case). git-cinnabar or git-remote-hg can be used by
> >> developers who prefer git when the server is mercurial. (full
> >> disclosure, I'm the author of git-cinnabar)
> >
> > Our source of truth is mercurial.  But our (Oracle Solaris) external,
> > read-only mirror is being moved from a mercurial repo on java.net to
> > github.
> 
> :-(

My thoughts exactly.

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

Re: hg-git and round-tripping (and file copies?)

[Danek Duvall]

Mike Hommey wrote:

> If your goal trying to round-trip between mercurial and git is to
> provide developers with the possibility to use mercurial or git as they
> like, and somehow make it work with developers pushing on both ends, you
> should instead use a single source of truth (mercurial or git, whichever
> you prefer keeping a server for), and let developers use conversion tools
> on their end. hg-git can be used by developers who prefer mercurial when
> the server is git (although it annoyingly adds visible metadata to git
> commits in that case). git-cinnabar or git-remote-hg can be used by
> developers who prefer git when the server is mercurial. (full
> disclosure, I'm the author of git-cinnabar)

Our source of truth is mercurial.  But our (Oracle Solaris) external,
read-only mirror is being moved from a mercurial repo on java.net to
github.  I would like for people who might have had clones of the mercurial
repo to be able to use hg-git to pull from the github repo and get the same
changeset IDs as they had before (and as we have internally), but that
looks like it's not possible.

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

Re: hg-git and round-tripping (and file copies?)

[Danek Duvall]

Gregory Szorc wrote:

> It is effectively impossible to round-trip between Git and Mercurial when
> file copies are involved. This is because Mercurial's filelog hashes
> include copy metadata and the parent nodes. Git's blob hashes, by contrast,
> are effectively content only. When you convert from Mercurial to Git, it
> will drop copy metadata (because Git doesn't track it explicitly). Then
> when you convert back to Mercurial, the copies have to be detected "just
> right" by hg-git for the hashes to align. Furthermore, the files have to be
> reintroduced in the same order, or the filelog parents may not align and
> the hashes may diverge. If a repo isn't linear, there's a non-zero chance
> of that happening.

Got it.

> It is best to have a single canonical repo and replicate from that.
> Attempting "syncing" from multiple discrete repos will only lead to
> divergence.

Sadly, that's not an option.  We're just going to have to deal with the
breakage, until such time as we can avoid the git intermediary.

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

Re: stable ordering of test output

[Danek Duvall]

Pierre-Yves David wrote:

> >>It's also a problem on the FreeBSD buildbot. I don't know enough about
> >>the bundle2 code to understand how to fix it, but maybe we can figure
> >>out a way to get marmoute an account on a machine taht would help him
> >>diagnose? Danek, do you have a solaris machine you could get him
> >>access to for testing purposes?
> >
> >Yeah, I tried to setup the BSD on the gcc compile farm to debug this,
> >but the machine have such ancient everything else that I finally gave up
> >(after recompiling my own python and a couple of dependency). I did not
> >had time to spend on this since that last attempt. Having an account on
> >something showing the issue would help.
> >
> >On the other hand, this is probably not so bundle2 specific. We have
> >some "select" logic to read stdout and stderr as soon as possible. This
> >is the main suspect as it is possible that this logic behave different
> >under linux and other unix (not too much effort have been put into it).
> >So there is not need of a deep knowledge of bundle2 to debug this if
> >someone else want to give it a shot.
> 
> As perr Augie request on IRC let me be more specific: I would have a look at
> the behavior of the logic in sshpeer.py using "doublepipe" class and the
> associated "util.poll".
> 
> It is responsible for reading the first stream that has data (of stderr and
> stdout). This kind of change in output seems to imply that either the server
> is flushing the stream in different order or that the "ready to read"
> detection is disabled or behaving differently.

It is in fact not specific to bundle2, as I'm also currently seeing the
problem in test-ssh-bundle1.

I would think this is an inherently racy problem, as with any asynchronous
execution, though I would then expect more variance in the results, so
perhaps I'm mistaken here.

It looks like my home machine reproduces the problem.  I'll set you up with
an account and send you the login info.

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

stable ordering of test output

[Danek Duvall]

I frequently get failures like this:

--- .../mercurial.hg/tests/test-bundle2-exchange.t
+++ .../mercurial.hg/tests/test-bundle2-exchange.t.err
@@ -1042,11 +1042,11 @@
   $ hg --config devel.legacy.exchange=bundle1 clone 
ssh://user@dummy/bundle2onlyserver not-bundle2-ssh
   requesting all changes
   adding changesets
-  remote: abort: incompatible Mercurial client; bundle2 required
-  remote: (see https://www.mercurial-scm.org/wiki/IncompatibleClient)
   transaction abort!
   rollback completed
   abort: stream ended unexpectedly (got 0 bytes, expected 4)
+  remote: abort: incompatible Mercurial client; bundle2 required
+  remote: (see https://www.mercurial-scm.org/wiki/IncompatibleClient)
   [255]
 
   $ cat > bundle2onlyserver/.hg/hgrc << EOF

ERROR: test-bundle2-exchange.t output changed

It's usually fairly consistent, at least for a period of time, and then it
goes away.  Presumably it's some sort of fairly stable timing issue, and
possibly unique to the environment I'm running in (at least, I assume that
the official tests aren't showing this).

I could patch the tests locally to reorder the lines, but if it's really an
environmental issue, then that's guaranteed to work consistently even for
me.

Is this (ever? frequently?) an issue for anyone else?

I can't think of any particularly satisfying solution to this, other than
perhaps separating the remote lines from the local lines, and comparing
each of those independently.  Would that make sense?

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

Re: [PATCH] merge: add resolve --prep, which outputs conflicted comparison files

[Danek Duvall]

Durham Goode wrote:

> On 2/27/17 11:09 AM, Danek Duvall wrote:
> >Durham Goode wrote:
> >
> >>On 2/24/17 4:10 PM, Danek Duvall wrote:
> >>
> >>>Is that the central issue?  That is, you want to run a tool once over all
> >>>unresolved files, rather than one at a time?
> >>>
> >>>It seems like perhaps a new config option for merge-tools could indicate
> >>>that it takes multiple files.  Then the question is whether the tool should
> >>>know how to generate the list of unresolved files and the various versions
> >>>of them that are involved in the resolution, or whether mercurial should
> >>>compute all that and pass it to the tool in some fashion.
> >>>
> >>>Likewise on the other end, the tool will need to communicate back to
> >>>mercurial which files are now considered resolved, and which ones aren't.
> >>>
> >>>Or am I misunderstanding what you're trying to do?
> >>>
> >>>Danek
> >>
> >>The high level goal is we want to provide an entire conflict experience via
> >>an IDE, so we need all data related to the merge conflicts (content of files
> >>at relevant revisions; type of conflict, like changed vs deleted, or
> >>directory vs file, or executable vs symlink) available at once, and not
> >>during a blocking Mercurial command.  The current merge tool logic doesn't
> >>handle any of those requirements.
> >
> >So why not consider this situation to be a new type of merge tool flag, and
> >then define the protocol for that kind of tool to be a commandline argument
> >of a json file with the necessary data?  It seems like both the original
> >proposal (emit json with a custom flag) and the updated one (emit json with
> >a custom merge tool) are less flexible, and involve more manual effort (you
> >still have to run your tool manually and pass it that json blob).
> 
> Do you mean something like, add a --merge-tool-json flag and mercurial
> executes the specified tool by passing a file path to a json file with the
> data we've been talking about?

By "flag", I meant a configuration variable, a la "gui" -- you would
effectively mark a particular tool as being one that took this json blob as
input and would mark conflicts as resolved independently from mercurial.
Add a new variable $json to "args", and then you can do

[merge-tools]
myIDE.executable = /path/to/wherever
myIDE.async = true
myIDE.args = --conflict-file $json

and whatever other things like gui, symlink, etc, that are true.

> In our scenario, where an IDE wants to receive all the conflict data and
> act on it asynchronously from mercurial's resolution logic, doing this
> using your proposal would mean we'd have to create a bash script or
> something that just copies the json file it's passed to some other
> location so the IDE can read that file after 'hg resolve
> --merge-tool-json simplecopytool.sh' exits (or otherwise communicates the
> information to the IDE somehow).

I don't really see the need for copying anything around.  Just stuff the
blob in a place that mercurial can tell the tool about, and don't remove it
until the tool says it's done.

> >Besides, you can run "hg resolve -l" and "hg cat -r ..." while in the
> >middle of the merge, so I'm not sure what you mean by the merge tool logic
> >doesn't allow you to do that.  Is it that "hg resolve -l" doesn't give you
> >enough data about what metadata is changing?
> 
> hg resolve doesn't give us information about the various versions of the
> file or information about the type of conflict, and even if it did give us
> the hashes of those versions, shelling out to hg cat for each one is
> excessively slow in large repos.

I see; sure.  Then either the tool can do it all with Python code calling
the mercurial bits (okay, probably not great), or the json blob just
includes paths to each version of each file, and mercurial lines them all
up ahead of time.  The tool can regenerate them if it comes to that.

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

Re: [PATCH] merge: add resolve --prep, which outputs conflicted comparison files

[Danek Duvall]

Durham Goode wrote:

> On 2/24/17 4:10 PM, Danek Duvall wrote:
>
> >Is that the central issue?  That is, you want to run a tool once over all
> >unresolved files, rather than one at a time?
> >
> >It seems like perhaps a new config option for merge-tools could indicate
> >that it takes multiple files.  Then the question is whether the tool should
> >know how to generate the list of unresolved files and the various versions
> >of them that are involved in the resolution, or whether mercurial should
> >compute all that and pass it to the tool in some fashion.
> >
> >Likewise on the other end, the tool will need to communicate back to
> >mercurial which files are now considered resolved, and which ones aren't.
> >
> >Or am I misunderstanding what you're trying to do?
> >
> >Danek
> 
> The high level goal is we want to provide an entire conflict experience via
> an IDE, so we need all data related to the merge conflicts (content of files
> at relevant revisions; type of conflict, like changed vs deleted, or
> directory vs file, or executable vs symlink) available at once, and not
> during a blocking Mercurial command.  The current merge tool logic doesn't
> handle any of those requirements.

So why not consider this situation to be a new type of merge tool flag, and
then define the protocol for that kind of tool to be a commandline argument
of a json file with the necessary data?  It seems like both the original
proposal (emit json with a custom flag) and the updated one (emit json with
a custom merge tool) are less flexible, and involve more manual effort (you
still have to run your tool manually and pass it that json blob).

Besides, you can run "hg resolve -l" and "hg cat -r ..." while in the
middle of the merge, so I'm not sure what you mean by the merge tool logic
doesn't allow you to do that.  Is it that "hg resolve -l" doesn't give you
enough data about what metadata is changing?

> For communicating back to Mercurial, 'hg resolve --mark file1 file2' already
> exists and is sufficient.

Definitely, assuming you want that to be part of the protocol.  You could
have a json blob to pass to mercurial "hg resolve -j " which could
then be extensible and work for other SCMs should they want to do something
similar.  Though perhaps simply a list of paths to be marked as no longer
in conflict is all you'd ever need.

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

Re: [PATCH] merge: add resolve --prep, which outputs conflicted comparison files

[Danek Duvall]

Durham Goode wrote:

> 
> 
> On 2/24/17 3:25 PM, Jun Wu wrote:
> >Excerpts from Durham Goode's message of 2017-02-24 15:18:40 -0800:
> >>On 2/23/17 2:57 PM, Jun Wu wrote:
> >>>Congratulations on your first patch to the list!
> >>>
> >>>But I think we have better ways to achieve the same goal that we may prefer
> >>>them to this patch.
> >>>
> >>>1) Better way to provide conflicted file contents - in-python merge tools
> >>>
> >>>  From a high-level, the patch tries to solve the problem:
> >>>
> >>>- Get all paths and file contents involved in merge conflict resolution
> >>>  in an efficient way.
> >>>
> >>>  We have "--list" and "--tool" already to fetch the data in a less 
> >>> efficient
> >>>  way. I'm not a big fan of a new flag doing what we can do today.
> >>>
> >>>  I think a better to achieve the "efficient" goal is to make "--tool"
> >>>  accept Python functions, just like what we do for hooks. If the signature
> >>>  of the Python function accepts file contents directly, we can even avoid
> >>>  writing temporary files - even more efficient than this patch.
> >>
> >>While that way may be more generic, and potentially more efficient in
> >>some cases, it puts a larger burden of understanding on the consumer.
> >>They would have to learn about Mercurial internals (or at least the api
> >>for the hook), write a python script, and package that script into their
> >>deployment.  Given that Mercurial already has knowledge of what data
> >>merge tools need, I think it's reasonable to just have an interface that
> >>prints that data for simple consumption.
> >
> >That shouldn't be an issue if we ship the Python merge function that
> >generates the format they want - what they need is to just put a single line
> >of config, like "merge-tool=somemod:jsonexport"
> 
> Maybe I don't understand your proposal.  The current merge-tools are invoked
> once per file.

Is that the central issue?  That is, you want to run a tool once over all
unresolved files, rather than one at a time?

It seems like perhaps a new config option for merge-tools could indicate
that it takes multiple files.  Then the question is whether the tool should
know how to generate the list of unresolved files and the various versions
of them that are involved in the resolution, or whether mercurial should
compute all that and pass it to the tool in some fashion.

Likewise on the other end, the tool will need to communicate back to
mercurial which files are now considered resolved, and which ones aren't.

Or am I misunderstanding what you're trying to do?

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

Re: [PATCH 1 of 8 ipv6] runtests: export HGIPV6 to hint test scripts whether to use IPv6

[Danek Duvall]

Jun Wu wrote:

> With all the changes, it'll be easy to switch between v4 and v6 (by changing
> "useipv6" in run-tests.py). I think we can add a new command line flag to
> run-tests.py so people can choose whether they want to test v4 or v6.

Or both?  Would it be useful consider one to be primary and the other
secondary, and to always test only a subset of networking-related tests on
the secondary if it's available?  Running the entire testsuite twice just
to make sure that nothing's broken on both IPv4 and IPv6 seems like
overkill to me.

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

Re: [PATCH 1 of 8 ipv6] runtests: export HGIPV6 to hint test scripts whether to use IPv6

[Danek Duvall]

Jun Wu wrote:

> # HG changeset patch
> # User Jun Wu 
> # Date 1487221422 28800
> #  Wed Feb 15 21:03:42 2017 -0800
> # Node ID f2743873dfbd6adedcd3aa1777b651ce5bd6f6ed
> # Parent  a70e11929c63cd9245812f3db8091a449cd1273e
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> f2743873dfbd
> runtests: export HGIPV6 to hint test scripts whether to use IPv6
> 
> Previously, run-tests.py only exports HGPORT, and scripts in tests do not
> know if IPv6 should be used. And that breaks scripts like dumbhttp.py which
> always uses IPv4.
> 
> This patch makes run-tests.py export HGIPV6, which can help test scripts
> like dumbhttp.py and tinyproxy.py to decide whether to use IPv6 or not.

So does this set of patches mean that if IPv6 is available on the test
machine, IPv4 won't be tested at all?

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

Re: [PATCH] merge: print status message before launching external merge tool

[Danek Duvall]

Martin von Zweigbergk via Mercurial-devel wrote:

> # HG changeset patch
> # User Martin von Zweigbergk 
> # Date 1486661545 28800
> #  Thu Feb 09 09:32:25 2017 -0800
> # Node ID 93d94750f3abee5b9798c41160a2102c61936133
> # Parent  1f51b4658f21bbb797e922d155c1046eddccf91d
> merge: print status message before launching external merge tool
> 
> It seems somewhat common that people run into a merge conflict and
> don't notice the launched merge tool, and instead they thing hg just
> hung. Let's print a message for each file that we launch the merge
> tool for.

Perhaps only if it's a gui invocation?  If it's in the terminal, it'll just
disappear in the noise.  If a window pops up (non-interactively), that's
when you might need the warning.

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

[PATCH STABLE] tests: account for different newline behavior between Solaris and GNU grep

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1485722456 28800
#  Sun Jan 29 12:40:56 2017 -0800
# Branch stable
# Node ID 24d82f28412d67323d13ac2b9f8c7c489c171ee0
# Parent  7bfe02b57695900ef996989286c1fdc2a13aec82
tests: account for different newline behavior between Solaris and GNU grep

GNU grep, when emitting a matching line that doesn't have a terminating
newline, will add an extra newline.  Solaris grep passes the original line
through without the newline.  This causes differences in test output when
looking at the last line of the output of get-with-headers.py, which
doesn't usually emit (and certainly doesn't guarantee) a terminating
newline.

Both grep implementations succeed in matching the requested pattern,
though, so rely on specifying the full pattern on grep's commandline
instead of expecting it in the output, and send the output to /dev/null.

diff --git a/tests/test-http-protocol.t b/tests/test-http-protocol.t
--- a/tests/test-http-protocol.t
+++ b/tests/test-http-protocol.t
@@ -16,11 +16,9 @@
 compression formats are advertised in compression capability
 
 #if zstd
-  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep compression
-  compression=zstd,zlib
+  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep '^compression=zstd,zlib$' > /dev/null
 #else
-  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep compression
-  compression=zlib
+  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep '^compression=zlib$' > /dev/null
 #endif
 
   $ killdaemons.py
@@ -29,8 +27,7 @@ server.compressionengines can replace en
 
   $ hg --config server.compressionengines=none -R server serve -p $HGPORT -d 
--pid-file hg.pid
   $ cat hg.pid > $DAEMON_PIDS
-  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep compression
-  compression=none
+  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep '^compression=none$' > /dev/null
 
   $ killdaemons.py
 
@@ -38,8 +35,7 @@ Order of engines can also change
 
   $ hg --config server.compressionengines=none,zlib -R server serve -p $HGPORT 
-d --pid-file hg.pid
   $ cat hg.pid > $DAEMON_PIDS
-  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep compression
-  compression=none,zlib
+  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' | 
grep '^compression=none,zlib$' > /dev/null
 
   $ killdaemons.py
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3 V2] revset: add a changes(file, fromline, toline[, rev]) revset

[Danek Duvall]

Denis Laxalde wrote:

> # HG changeset patch
> # User Denis Laxalde 
> # Date 1480086890 -3600
> #  Fri Nov 25 16:14:50 2016 +0100
> # Node ID 5e5ec2ade2cfc829cffba145193da5801c5b20e7
> # Parent  c8dfd10c5865cfe882a00595743f3f709f41317f
> # EXP-Topic linerange-log/revset
> revset: add a changes(file, fromline, toline[, rev]) revset

What's the use-case for this?  Being able to track changes to some sort of
syntax block (like a function, paragraph, etc) seems far more valuable than
a fixed line range (albeit substantially more difficult to implement).

> +  $ hg log -r 'changes(baz, 2, 40)'
> +  abort: line range exceeds file size
> +  [255]

This test seems a bit odd, since a file might change its size over time,
and you might want to track lines 2-40, even though the file might not have
at least 40 lines over the course of its history.

Perhaps the revset simply needs more user-facing documentation for those of
us without enough imagination?

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

Re: [PATCH] tests: make test-convert-git.t reproducible

[Danek Duvall]

Gregory Szorc wrote:

> # HG changeset patch
> # User Gregory Szorc 
> # Date 1482601208 25200
> #  Sat Dec 24 10:40:08 2016 -0700
> # Node ID ee1c5cef44af3163e95858f23730b6bd1d035595
> # Parent  b2be4ccaff1d89356cbd9637aa9191e8048012b6
> tests: make test-convert-git.t reproducible
> 
> For reasons I can't explain, Git's copy detection code was identifying
> different source files on OS X and (presumably) Solaris versus Linux
> (which the test was originally authored against). This was causing
> unstable test output.
> 
> Changing the test to use a non-ambiguous source file appears to make
> the test stable.

Just wanted to confirm that this did in fact solve my problem on Solaris.

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

Re: [PATCH] convert: config option for git rename limit

[Danek Duvall]

I got this in my test run last night:

--- .../tests/test-convert-git.t
+++ .../tests/test-convert-git.t.err
@@ -397,7 +397,7 @@
   A bar-copy0
 bar
   A bar-copy1
-bar
+bar-copied2

Haven't tracked it down yet, but I thought I'd make a note in case it was
obvious to you.  My git version is 2.7.4, if that's relevant here.

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

Re: more symlink woes

[Danek Duvall]

Danek Duvall wrote:

> I got this with last night's bits.  I'm not sure what would be causing it,
> though.

What would be causing it is the remnants of a patch I had backing out one
of the previous symlink changes.  Clearing that up fixes everything.

Sorry for the false alarm.

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

Re: more symlink woes

[Danek Duvall]

Augie Fackler wrote:

> On Tue, Dec 6, 2016 at 12:35 PM, Danek Duvall <danek.duv...@oracle.com> wrote:
> > I got this with last night's bits.  I'm not sure what would be causing it,
> > though.
> 
> This on some flavor of Solaris?

Yep.

Danek

> >
> > --- .../tests/test-symlink-os-yes-fs-no.py.out
> > +++ .../tests/test-symlink-os-yes-fs-no.py.err
> > @@ -5,6 +5,8 @@
> >  added 1 changesets with 4 changes to 4 files
> >  updating to branch default
> >  4 files updated, 0 files merged, 0 files removed, 0 files unresolved
> > +M a.lnk
> > +M d/b.lnk
> >  requesting all changes
> >  adding changesets
> >  adding manifests
> >
> > Thanks,
> > Danek
> > ___
> > 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

more symlink woes

[Danek Duvall]

I got this with last night's bits.  I'm not sure what would be causing it,
though.

--- .../tests/test-symlink-os-yes-fs-no.py.out
+++ .../tests/test-symlink-os-yes-fs-no.py.err
@@ -5,6 +5,8 @@
 added 1 changesets with 4 changes to 4 files
 updating to branch default
 4 files updated, 0 files merged, 0 files removed, 0 files unresolved
+M a.lnk
+M d/b.lnk
 requesting all changes
 adding changesets
 adding manifests

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

Re: [PATCH 1 of 2] tests: use cp -R instead of cp -r

[Danek Duvall]

Jun Wu wrote:

> Excerpts from Danek Duvall's message of 2016-11-30 09:51:11 -0800:
> > Jun Wu wrote:
> > 
> > > # HG changeset patch
> > > # User Jun Wu 
> > > # Date 1480526736 0
> > > #  Wed Nov 30 17:25:36 2016 +
> > > # Node ID a4f46a03e5f8e33f32c36326c6b14b84d9cb03b4
> > > # Parent  9e29d4e4e08b5996adda49cdd0b497d89e2b16ee
> > > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > > #  hg pull https://bitbucket.org/quark-zju/hg-draft  -r 
> > > a4f46a03e5f8
> > > tests: use cp -R instead of cp -r
> > > 
> > > This makes OS X happy for some tests after 0d87b1caed92. The default
> > > behavior of -R (-P, not follow symlinks) is what we want.
> > 
> > Where is that documented?  The GNU cp manpage considers -r and -R to be the
> > same, and the Solaris manpage says that -R is the same as -r, except pipes
> > are replicated instead of read from.
> See:
> 
> - http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html

I'm not sure how you get that.

   If source_file is a file of type symbolic link:

   - If the -R option was specified:

 - If none of the options -H, -L, nor -P were specified, it is
   unspecified which of -H, -L, or -P will be used as a default.

> - 
> https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/cp.1.html

I guess MacOS chose -P; Solaris didn't.

Seems reasonable to use -R instead of -r, but I think -P will be required,
too.

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

Re: [PATCH 1 of 2] tests: use cp -R instead of cp -r

[Danek Duvall]

Jun Wu wrote:

> # HG changeset patch
> # User Jun Wu 
> # Date 1480526736 0
> #  Wed Nov 30 17:25:36 2016 +
> # Node ID a4f46a03e5f8e33f32c36326c6b14b84d9cb03b4
> # Parent  9e29d4e4e08b5996adda49cdd0b497d89e2b16ee
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> a4f46a03e5f8
> tests: use cp -R instead of cp -r
> 
> This makes OS X happy for some tests after 0d87b1caed92. The default
> behavior of -R (-P, not follow symlinks) is what we want.

Where is that documented?  The GNU cp manpage considers -r and -R to be the
same, and the Solaris manpage says that -R is the same as -r, except pipes
are replicated instead of read from.

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

Re: [PATCH 5 of 5] posix: give checklink a fast path that cache the check file and is read only

[Danek Duvall]

Danek Duvall wrote:

> I tried adding "delete=(cachedir is None)" (or the equivalent) to the
> NamedTemporaryFile call, and that cleared up all the cp -r errors, but left
> behind three tests failing due to the files left behind.  At least two of
> them are straightforward to fix, I think, since they're just the output of
> ls commands, but the ones in test-hardlinks.t I'm not so sure about.

I'm wondering if util.copyfiles() needs to be smarter about copying/linking
symlinks.  But I could just add "| grep -v checklink" to those tests and
sweep it under the rug.

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

Re: [PATCH 5 of 5] posix: give checklink a fast path that cache the check file and is read only

[Danek Duvall]

Mads Kiilerich wrote:

> # HG changeset patch
> # User Mads Kiilerich 
> # Date 1421194526 -3600
> #  Wed Jan 14 01:15:26 2015 +0100
> # Node ID 73b671fbed41d82a5dd46e485c61ddb8afe42faf
> # Parent  5409e0c5e6c0764e802360a3912f7719885ba2b5
> posix: give checklink a fast path that cache the check file and is read only
> 
> util.checklink would create a symlink and remove it again. That would 
> sometimes
> happen multiple times. Write operations are relatively expensive and give disk
> tear and noise for applications monitoring file system activity.
> 
> Instead of creating a symlink and deleting it again, just create it once and
> leave it in .hg/cache/check-link . If the file exists, just verify that
> os.islink reports true. We will assume that this check is as good as symlink
> creation not failing.
> 
> Note: The symlink left in .hg/cache has to resolve to a file - otherwise 'make
> dist' will fail ...
> 
> test-symlink-os-yes-fs-no.py does some monkey patching to simulate a platform
> without symlink support. The slightly different testing method requires
> additional monkeying.
> 
> diff --git a/mercurial/posix.py b/mercurial/posix.py
> --- a/mercurial/posix.py
> +++ b/mercurial/posix.py
> @@ -220,6 +220,10 @@ def checklink(path):
>  # file already exists
>  while True:
>  cachedir = os.path.join(path, '.hg', 'cache')
> +checklink = os.path.join(cachedir, 'checklink')
> +# try fast path, read only
> +if os.path.islink(checklink):
> +return True
>  if os.path.isdir(cachedir):
>  checkdir = cachedir
>  else:
> @@ -231,7 +235,13 @@ def checklink(path):
>   prefix='hg-checklink-')
>  try:
>  os.symlink(os.path.basename(fd.name), name)
> -os.unlink(name)
> +if cachedir is None:
> +os.unlink(name)
> +else:
> +try:
> +os.rename(name, checklink)
> +except OSError:
> +os.unlink(name)
>  return True

I'm a little confused by this.  Since fd refers to a temporary file that
gets deleted when the variable goes out of scope, then checklink ends up
dangling after all, violating your Note in the description.

A handful of tests fail on Solaris because "cp -r" follows symlinks by
default, and it squawks on all the dangling checklink files.  That's
obviously related to this somehow, though whether or not it's specifically
because of that I'm not positive.

I could fix it by making all the failing cp -r calls be cp -rP, but I don't
really like that solution.

I tried adding "delete=(cachedir is None)" (or the equivalent) to the
NamedTemporaryFile call, and that cleared up all the cp -r errors, but left
behind three tests failing due to the files left behind.  At least two of
them are straightforward to fix, I think, since they're just the output of
ls commands, but the ones in test-hardlinks.t I'm not so sure about.

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

Re: [PATCH] zstd: fix compilation with Solaris Studio

[Danek Duvall]

Gregory Szorc wrote:

> > Cool.  FWIW, the mercurial build didn't fail when I got this failure, which
> > I found a bit surprising.  I get the desire to make sure that the zstd
> > support isn't critical, but if I hadn't known to go look for this, I would
> > have missed it entirely until at some point I checked to see that the zstd
> > bits were, in fact, being delivered.  There's probably a happy medium
> > somewhere.
> >
> 
> Uhh - that shouldn't happen!
> 
> distutils does support optional extensions, but we don't have that flag set
> in setup.py. When I `make local` or `python setup.py build_ext` with a
> "bad" .c file from python-zstandard/c-ext, I get an "error: command 'gcc'
> failed with exit status 1" and setup.py aborts. I'm really curious what
> your machine is up to!

Oh.  Because it's a *warning*, so the exit code is 0.  Here's the full
error:

".../compressionparams.c", line 139: warning: syntax error:  empty 
declaration

The module didn't show up in my manifest because the new manifest wasn't
generated due to (hopefully unrelated) test failures.

So uh, the patch isn't critical, but we could still do without the warning.

Now to figure out the test failures.  :-/  I should really get that
buildbot instance up so it's not all on me.  :)

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

Re: [PATCH] zstd: fix compilation with Solaris Studio

[Danek Duvall]

Gregory Szorc wrote:

> On Tue, Nov 22, 2016 at 1:34 PM, <danek.duv...@oracle.com> wrote:
> 
> > # HG changeset patch
> > # User Danek Duvall <danek.duv...@oracle.com>
> > # Date 1479850325 28800
> > #  Tue Nov 22 13:32:05 2016 -0800
> > # Node ID b09fb7f66e9e680358b8fb359be24a14fd6b3cfb
> > # Parent  8836f13e3c5b8eae765372708b659c55a044cbb4
> > zstd: fix compilation with Solaris Studio
> >
> > Without these changes, Solaris Studio (12.4) gives us "syntax error: empty
> > declaration" on these two lines.
> >
> 
> Doh.
> 
> This patch LGTM. I've applied this upstream as well and it will be in the
> next python-zstandard release. The canonical upstream is
> https://github.com/indygreg/python-zstandard by the way (although I haven't
> pushed the fix there yet).

Cool.  FWIW, the mercurial build didn't fail when I got this failure, which
I found a bit surprising.  I get the desire to make sure that the zstd
support isn't critical, but if I hadn't known to go look for this, I would
have missed it entirely until at some point I checked to see that the zstd
bits were, in fact, being delivered.  There's probably a happy medium
somewhere.

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

[PATCH] zstd: fix compilation with Solaris Studio

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1479850325 28800
#  Tue Nov 22 13:32:05 2016 -0800
# Node ID b09fb7f66e9e680358b8fb359be24a14fd6b3cfb
# Parent  8836f13e3c5b8eae765372708b659c55a044cbb4
zstd: fix compilation with Solaris Studio

Without these changes, Solaris Studio (12.4) gives us "syntax error: empty
declaration" on these two lines.

diff --git a/contrib/python-zstandard/c-ext/compressionparams.c 
b/contrib/python-zstandard/c-ext/compressionparams.c
--- a/contrib/python-zstandard/c-ext/compressionparams.c
+++ b/contrib/python-zstandard/c-ext/compressionparams.c
@@ -136,7 +136,7 @@ static void CompressionParameters_deallo
 
 static Py_ssize_t CompressionParameters_length(PyObject* self) {
return 7;
-};
+}
 
 static PyObject* CompressionParameters_item(PyObject* o, Py_ssize_t i) {
CompressionParametersObject* self = (CompressionParametersObject*)o;
diff --git a/contrib/python-zstandard/c-ext/dictparams.c 
b/contrib/python-zstandard/c-ext/dictparams.c
--- a/contrib/python-zstandard/c-ext/dictparams.c
+++ b/contrib/python-zstandard/c-ext/dictparams.c
@@ -42,7 +42,7 @@ static void DictParameters_dealloc(PyObj
 
 static Py_ssize_t DictParameters_length(PyObject* self) {
return 4;
-};
+}
 
 static PyObject* DictParameters_item(PyObject* o, Py_ssize_t i) {
DictParametersObject* self = (DictParametersObject*)o;
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH STABLE] tests: run "cwd was removed" test only if cwd can actually be removed

[Danek Duvall]

Yuya Nishihara wrote:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1477489806 -32400
> #  Wed Oct 26 22:50:06 2016 +0900
> # Branch stable
> # Node ID d389b88b942adb330819437ef46d1b9acb4392d7
> # Parent  b9f7b0c10027764cee77f9c6d61877fcffea837f
> tests: run "cwd was removed" test only if cwd can actually be removed
> 
> On some platforms, cwd can't be removed. In which case, util.unlinkpath()
> continues with no error since the failure isn't critical.

The problem here is a bit more specific: while Linux (for example) prevents
you from removing cwd when referring to it as ".", Solaris prevents you
from removing it under all names.  So because that failure isn't critical,
the cwd ends up remaining behind on Solaris because it's done via the full
path.  It might make sense to be more specific in the name, too, though I'm
not sure what to suggest.

There's also a second test that has some related output:

--- a/tests/test-rebase-scenario-global.t
+++ b/tests/test-rebase-scenario-global.t
@@ -758,8 +758,6 @@ Test that rebase is not confused by $CWD
   $ 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)

is what I had to remove temporarily.

Thanks,
Danek
___
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

[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

[PATCH] color: add some documentation for custom terminfo codes

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1476568874 25200
#  Sat Oct 15 15:01:14 2016 -0700
# Node ID 42f5a2db9e7f9d66058a7d77bc8c0c263272a8de
# Parent  c59334b806a8f10c80c2ea196eba5f4b1b86b229
color: add some documentation for custom terminfo codes

diff --git a/hgext/color.py b/hgext/color.py
--- a/hgext/color.py
+++ b/hgext/color.py
@@ -29,6 +29,15 @@ ECMA-48 mode, the options are 'bold', 'i
 Some may not be available for a given terminal type, and will be
 silently ignored.
 
+If the terminfo entry for your terminal is missing codes for an effect
+or has the wrong codes, you can add or override those codes in your
+configuration::
+
+  [color]
+  terminfo.dim = \E[2m
+
+where '\E' is substituted with an escape character.
+
 Labels
 --
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] color: debugcolor should emit the user-defined colors

[Danek Duvall]

Yuya Nishihara wrote:

> On Thu, 13 Oct 2016 13:27:35 -0700, danek.duv...@oracle.com wrote:
> > # HG changeset patch
> > # User Danek Duvall <danek.duv...@oracle.com>
> > # Date 1476389401 25200
> > #  Thu Oct 13 13:10:01 2016 -0700
> > # Node ID c59334b806a8f10c80c2ea196eba5f4b1b86b229
> > # Parent  333e875ce30da3760c8655e303d9bea554efe7e4
> > color: debugcolor should emit the user-defined colors
> > 
> > This also fixes a long-standing bug that reversed the sense of the color
> > name and the label used to print it, which was never relevant before.
> > 
> > diff --git a/hgext/color.py b/hgext/color.py
> > --- a/hgext/color.py
> > +++ b/hgext/color.py
> > @@ -524,10 +524,16 @@ def debugcolor(ui, repo, **opts):
> >  _styles = {}
> >  for effect in _effects.keys():
> >  _styles[effect] = effect
> > +if _terminfo_params:
> > +for k, v in ui.configitems('color'):
> > +if k.startswith('color.'):
> > +_styles[k] = k[6:]
> > +elif k.startswith('terminfo.'):
> > +_styles[k] = k[9:]
> >  ui.write(('color mode: %s\n') % ui._colormode)
> >  ui.write(_('available colors:\n'))
> > -for label, colors in _styles.items():
> > -ui.write(('%s\n') % colors, label=label)
> > +for colorname, label in _styles.items():
> > +ui.write(('%s\n') % colorname, label=label)
> 
> I was surprised to know that a label can be a valid effect name.

This bit confused me for a while, and maybe I didn't make things better in
that regard.  There's "label" in the sense of the keyword argument to
ui.write(), and "label" in the sense of the word that we're printing out
here, labelling the color.  I used the latter sense in my comment, but the
code uses the former sense.

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

Re: [PATCH 1 of 3] color: allow for user-configurable terminfo codes for effects

[Danek Duvall]

Yuya Nishihara wrote:

> On Thu, 13 Oct 2016 13:27:33 -0700, danek.duv...@oracle.com wrote:
> > # HG changeset patch
> > # User Danek Duvall <danek.duv...@oracle.com>
> > # Date 1476384497 25200
> > #  Thu Oct 13 11:48:17 2016 -0700
> > # Node ID 61e74a19770c2ce80c0cedc429915112261e5c1b
> > # Parent  4d93d73b8aecb2436bbfe9248cdfe0ef21582baf
> > color: allow for user-configurable terminfo codes for effects
> 
> The series looks good to me. Queued, thanks.

Thanks!

> > If the entry in the terminfo database for your terminal is missing some
> > attributes, it should be possible to create them on the fly without
> > resorting to just making them a color.  This change allows you to have
> > 
> > [color]
> > terminfo. = 
> > 
> > where  might be something like "dim" or "bold", and  is the
> > escape sequence that would otherwise have come from a call to tigetstr().
> > If an escape character is needed, use "\E".  Any such settings will
> > override attributes that are present in the terminfo database.
> 
> Can you update the doc as a follow-up?

Patch should be on its way.

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

[PATCH 1 of 3] color: allow for user-configurable terminfo codes for effects

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1476384497 25200
#  Thu Oct 13 11:48:17 2016 -0700
# Node ID 61e74a19770c2ce80c0cedc429915112261e5c1b
# Parent  4d93d73b8aecb2436bbfe9248cdfe0ef21582baf
color: allow for user-configurable terminfo codes for effects

If the entry in the terminfo database for your terminal is missing some
attributes, it should be possible to create them on the fly without
resorting to just making them a color.  This change allows you to have

[color]
terminfo. = 

where  might be something like "dim" or "bold", and  is the
escape sequence that would otherwise have come from a call to tigetstr().
If an escape character is needed, use "\E".  Any such settings will
override attributes that are present in the terminfo database.

diff --git a/hgext/color.py b/hgext/color.py
--- a/hgext/color.py
+++ b/hgext/color.py
@@ -187,9 +187,12 @@ def _terminfosetup(ui, mode):
 if mode not in ('auto', 'terminfo'):
 return
 
-_terminfo_params.update((key[6:], (False, int(val)))
+_terminfo_params.update((key[6:], (False, int(val), ''))
 for key, val in ui.configitems('color')
 if key.startswith('color.'))
+_terminfo_params.update((key[9:], (True, '', val.replace('\\E', '\x1b')))
+for key, val in ui.configitems('color')
+if key.startswith('terminfo.'))
 
 try:
 curses.setupterm()
@@ -197,10 +200,10 @@ def _terminfosetup(ui, mode):
 _terminfo_params = {}
 return
 
-for key, (b, e) in _terminfo_params.items():
+for key, (b, e, c) in _terminfo_params.items():
 if not b:
 continue
-if not curses.tigetstr(e):
+if not c and not curses.tigetstr(e):
 # Most terminals don't support dim, invis, etc, so don't be
 # noisy and use ui.debug().
 ui.debug("no terminfo entry for %s\n" % e)
@@ -281,26 +284,26 @@ def _modesetup(ui, coloropt):
 
 try:
 import curses
-# Mapping from effect name to terminfo attribute name or color number.
-# This will also force-load the curses module.
-_terminfo_params = {'none': (True, 'sgr0'),
-'standout': (True, 'smso'),
-'underline': (True, 'smul'),
-'reverse': (True, 'rev'),
-'inverse': (True, 'rev'),
-'blink': (True, 'blink'),
-'dim': (True, 'dim'),
-'bold': (True, 'bold'),
-'invisible': (True, 'invis'),
-'italic': (True, 'sitm'),
-'black': (False, curses.COLOR_BLACK),
-'red': (False, curses.COLOR_RED),
-'green': (False, curses.COLOR_GREEN),
-'yellow': (False, curses.COLOR_YELLOW),
-'blue': (False, curses.COLOR_BLUE),
-'magenta': (False, curses.COLOR_MAGENTA),
-'cyan': (False, curses.COLOR_CYAN),
-'white': (False, curses.COLOR_WHITE)}
+# Mapping from effect name to terminfo attribute name (or raw code) or
+# color number.  This will also force-load the curses module.
+_terminfo_params = {'none': (True, 'sgr0', ''),
+'standout': (True, 'smso', ''),
+'underline': (True, 'smul', ''),
+'reverse': (True, 'rev', ''),
+'inverse': (True, 'rev', ''),
+'blink': (True, 'blink', ''),
+'dim': (True, 'dim', ''),
+'bold': (True, 'bold', ''),
+'invisible': (True, 'invis', ''),
+'italic': (True, 'sitm', ''),
+'black': (False, curses.COLOR_BLACK, ''),
+'red': (False, curses.COLOR_RED, ''),
+'green': (False, curses.COLOR_GREEN, ''),
+'yellow': (False, curses.COLOR_YELLOW, ''),
+'blue': (False, curses.COLOR_BLUE, ''),
+'magenta': (False, curses.COLOR_MAGENTA, ''),
+'cyan': (False, curses.COLOR_CYAN, ''),
+'white': (False, curses.COLOR_WHITE, '')}
 except ImportError:
 _terminfo_params = {}
 
@@ -366,9 +369,12 @@ def _effect_str(effect):
 if effect.endswith('_background'):
 bg = True
 effect = effect[:-11]
-attr, val = _terminfo_params[effect]
+attr, val, termcode = _terminfo_params[effect]
 if attr:
-return curses.tigetstr(val)
+if termcode:
+return termcode
+else:
+return curses.tigetstr(val)
 elif bg:
 return curses.tparm(curses.tigetstr('setab'), val)
 else:
@@ -403,7 +409,7 @@ def valideffect(effect):
 
 def

[PATCH 3 of 3] color: debugcolor should emit the user-defined colors

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1476389401 25200
#  Thu Oct 13 13:10:01 2016 -0700
# Node ID c59334b806a8f10c80c2ea196eba5f4b1b86b229
# Parent  333e875ce30da3760c8655e303d9bea554efe7e4
color: debugcolor should emit the user-defined colors

This also fixes a long-standing bug that reversed the sense of the color
name and the label used to print it, which was never relevant before.

diff --git a/hgext/color.py b/hgext/color.py
--- a/hgext/color.py
+++ b/hgext/color.py
@@ -524,10 +524,16 @@ def debugcolor(ui, repo, **opts):
 _styles = {}
 for effect in _effects.keys():
 _styles[effect] = effect
+if _terminfo_params:
+for k, v in ui.configitems('color'):
+if k.startswith('color.'):
+_styles[k] = k[6:]
+elif k.startswith('terminfo.'):
+_styles[k] = k[9:]
 ui.write(('color mode: %s\n') % ui._colormode)
 ui.write(_('available colors:\n'))
-for label, colors in _styles.items():
-ui.write(('%s\n') % colors, label=label)
+for colorname, label in _styles.items():
+ui.write(('%s\n') % colorname, label=label)
 
 if os.name != 'nt':
 w32effects = None
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] color: replace "purple_background" by "magenta_background"

[Danek Duvall]

Pierre-Yves David wrote:

> 
> 
> On 10/11/2016 11:39 AM, Denis Laxalde wrote:
> ># HG changeset patch
> ># User Denis Laxalde 
> ># Date 1476176128 -7200
> >#  Tue Oct 11 10:55:28 2016 +0200
> ># Node ID 1cf20c1c54cb8172816604de5e1d98d3cd62d711
> ># Parent  b85fa6bf298be07804a74d8fdec0d19fdbc6d740
> ># EXP-Topic color-purple-crash
> >color: replace "purple_background" by "magenta_background"
> 
> We probably want to keep both value around for backward compatibility
> reason.
> 
> I'm also a bit curious about what all this is about. Can I convinced you to
> dig it a bit further?

_effect_str() strips "_background" off of an effect name to grab the color
name so it can figure out what color code to use.  Since we define
"purple_background", but "magenta" instead of "purple" (and
"magenta_background" doesn't exist, either), then this blows up.

I'll be sending out a patch shortly that just covers up this KeyError, but
either defining purple or magenta_background (or, probably, both) probably
ought to be done, anyway.

Danek

> >`hg debugcolor` crashes on my terminal:
> >
> >  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 530, in 
> > debugcolor
> >ui.write(('%s\n') % colors, label=label)
> >  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 446, in 
> > write
> >*[self.label(a, label) for a in args], **opts)
> >  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 488, in 
> > label
> >for s in msg.split('\n')])
> >  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 396, in 
> > render_effects
> >for effect in ['none'] + effects.split())
> >  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 396, in 
> > 
> >for effect in ['none'] + effects.split())
> >  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 378, in 
> > _effect_str
> >attr, val = _terminfo_params[effect]
> >KeyError: 'purple'
> >
> >Not sure where this "purple" comes (been there from initial file check in)
> >from but "magenta" seems more appropriate.
> >
> >diff --git a/hgext/color.py b/hgext/color.py
> >--- a/hgext/color.py
> >+++ b/hgext/color.py
> >@@ -182,7 +182,7 @@ testedwith = 'ships-with-hg-core'
> > 'italic': 3, 'underline': 4, 'inverse': 7, 'dim': 2,
> > 'black_background': 40, 'red_background': 41,
> > 'green_background': 42, 'yellow_background': 43,
> >-'blue_background': 44, 'purple_background': 45,
> >+'blue_background': 44, 'magenta_background': 45,
> > 'cyan_background': 46, 'white_background': 47}
> >
> > def _terminfosetup(ui, mode):
> >@@ -591,7 +591,7 @@ else:
> > 'green_background': _BACKGROUND_GREEN,
> > 'yellow_background': _BACKGROUND_RED | _BACKGROUND_GREEN,
> > 'blue_background': _BACKGROUND_BLUE,
> >-'purple_background': _BACKGROUND_BLUE | _BACKGROUND_RED,
> >+'magenta_background': _BACKGROUND_BLUE | _BACKGROUND_RED,
> > 'cyan_background': _BACKGROUND_BLUE | _BACKGROUND_GREEN,
> > 'white_background': (_BACKGROUND_RED | _BACKGROUND_GREEN |
> >  _BACKGROUND_BLUE),
> >___
> >Mercurial-devel mailing list
> >Mercurial-devel@mercurial-scm.org
> >https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> >
> 
> -- 
> 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

[PATCH 2 of 3] color: ignore effects missing from terminfo

[danek . duvall]

# HG changeset patch
# User Danek Duvall <danek.duv...@oracle.com>
# Date 1476385301 25200
#  Thu Oct 13 12:01:41 2016 -0700
# Node ID 333e875ce30da3760c8655e303d9bea554efe7e4
# Parent  61e74a19770c2ce80c0cedc429915112261e5c1b
color: ignore effects missing from terminfo

If terminfo mode is in effect, and an effect is used which is missing from
the terminfo database, simply silently ignore the request, leaving the
output unaffected rather than causing a crash.

diff --git a/hgext/color.py b/hgext/color.py
--- a/hgext/color.py
+++ b/hgext/color.py
@@ -369,7 +369,10 @@ def _effect_str(effect):
 if effect.endswith('_background'):
 bg = True
 effect = effect[:-11]
-attr, val, termcode = _terminfo_params[effect]
+try:
+attr, val, termcode = _terminfo_params[effect]
+except KeyError:
+return ''
 if attr:
 if termcode:
 return termcode
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 3] test-gpg: start gpg-agent under control of the test runner

[Danek Duvall]

Yuya Nishihara wrote:

> > I got an error here:
> > 
> > --- test-gpg.t  2016-08-26 20:00:15.146215645 -0700
> > +++ test-gpg.t.err  2016-08-26 20:06:43.142508667 -0700
> > @@ -17,6 +17,8 @@
> >  #if gpg2
> >$ gpg-connect-agent -q --subst /serverpid '/echo ${get serverpid}' 
> > /bye \
> >> >> $DAEMON_PIDS
> > +  gpg-connect-agent: can't connect to the agent: IPC connect call 
> > failed
> > +  [1]
> >$ gpg --no-permission-warning --no-secmem-warning --list-secret-keys 
> > \
> >> > /dev/null 2>&1
> >  #endif
> 
> Can you provide "gpg --version" ?

gpg (GnuPG) 2.0.30
libgcrypt 1.7.2
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

> > which seems reasonable, since gpg-agent hasn't actually been started yet.
> > The command -- gpg-connect-agent -- seems out of place with the comment,
> > which talks about gpg-agent.
> > 
> > What's actually supposed to happen?  Is gpg supposed to start gpg-agent in
> > the background?  If so, then shouldn't using gpg-connect-agent to get the
> > agent's pid come after that?
> 
> The man page says gpg-connect-agent starts gpg-agent. What I want is to spawn
> gpg-agent and wait to get pid.
> 
> https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html

Neither the info page nor the man page on my system say that.  Looks like
this is a feature that's new with 2.1?  I can probably try to get us
upgraded to 2.1, but the fact that 2.0.x is labeled "stable" and continues
to get updates probably doesn't help any.

I can patch my local copy if you don't want to support gpg 2.0.

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