[PATCH 8 of 9 v2] stdio: raise StdioError if something goes wrong in ui.flush

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID 800f9ec2664e515d8ad807c0df1efaccda8ff5e5
# Parent  fa74f393eaa5663b943eb0544ad4723ae7371385
stdio: raise StdioError if something goes wrong in ui.flush

The prior code used to ignore all errors, which was intended to
deal with a decade-old problem with writing to broken pipes on
Windows.

However, that code inadvertantly went a lot further, making it
impossible to detect *all* I/O errors on stdio ... but only sometimes.

What actually happened was that if Mercurial wrote less than a stdio
buffer's worth of output (the overwhelmingly common case for most
commands), any error that occurred would get swallowed here.  But
if the buffering strategy changed, an unhandled IOError could be
raised from any number of other locations.

Because we now have a top-level StdioError handler, and ui._write
and ui._write_err (and now flush!) will raise that exception, we
have one rational place to detect and handle these errors.

diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -807,10 +807,15 @@ class ui(object):
 # opencode timeblockedsection because this is a critical path
 starttime = util.timer()
 try:
-try: self.fout.flush()
-except (IOError, ValueError): pass
-try: self.ferr.flush()
-except (IOError, ValueError): pass
+try:
+self.fout.flush()
+except IOError as err:
+raise error.StdioError(err)
+finally:
+try:
+self.ferr.flush()
+except IOError as err:
+raise error.StdioError(err)
 finally:
 self._blockedtimes['stdio_blocked'] += \
 (util.timer() - starttime) * 1000
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 7 of 9 v2] stdio: raise StdioError if something goes wrong in ui._write_err

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID fa74f393eaa5663b943eb0544ad4723ae7371385
# Parent  e2a4bc13996100c5409f2e8561143e9fdad758a9
stdio: raise StdioError if something goes wrong in ui._write_err

The prior code used to ignore certain classes of error, which was
not the right thing to do.

diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -801,8 +801,7 @@ class ui(object):
 if not getattr(self.ferr, 'closed', False):
 self.ferr.flush()
 except IOError as inst:
-if inst.errno not in (errno.EPIPE, errno.EIO, errno.EBADF):
-raise
+raise error.StdioError(inst)
 
 def flush(self):
 # opencode timeblockedsection because this is a critical path
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 9 of 9 v2] stdio: add Linux-specific tests for error checking

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID 19530f1d18bc0b6697f2996f089c614548f90269
# Parent  800f9ec2664e515d8ad807c0df1efaccda8ff5e5
stdio: add Linux-specific tests for error checking

diff --git a/tests/hghave.py b/tests/hghave.py
--- a/tests/hghave.py
+++ b/tests/hghave.py
@@ -634,3 +634,7 @@ def has_zstd():
 return True
 except ImportError:
 return False
+
+@check("devfull", "/dev/full special file")
+def has_dev_full():
+return os.path.exists('/dev/full')
diff --git a/tests/test-basic.t b/tests/test-basic.t
--- a/tests/test-basic.t
+++ b/tests/test-basic.t
@@ -16,10 +16,31 @@ Create a repository:
   $ hg init t
   $ cd t
 
-Make a changeset:
+Prepare a changeset:
 
   $ echo a > a
   $ hg add a
+
+  $ hg status
+  A a
+
+Writes to stdio succeed and fail appropriately
+
+#if devfull
+  $ hg status 2>/dev/full
+  A a
+
+  $ hg status >/dev/full
+  abort: No space left on device
+  [255]
+
+  $ hg status >/dev/full 2>&1
+  [1]
+
+  $ hg status ENOENT 2>/dev/full
+  [1]
+#endif
+
   $ hg commit -m test
 
 This command is ancient:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 6 of 9 v2] stdio: raise StdioError if something goes wrong in ui._write

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID e2a4bc13996100c5409f2e8561143e9fdad758a9
# Parent  942022da49166766fe4a7967b71411879221c197
stdio: raise StdioError if something goes wrong in ui._write

diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -768,6 +768,8 @@ class ui(object):
 try:
 for a in msgs:
 self.fout.write(a)
+except IOError as err:
+raise error.StdioError(err)
 finally:
 self._blockedtimes['stdio_blocked'] += \
 (util.timer() - starttime) * 1000
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 5 of 9 v2] stdio: catch StdioError in dispatch.run and clean up appropriately

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID 942022da49166766fe4a7967b71411879221c197
# Parent  a5aa1dfd9afed15c0cd762c4a72e5e0082ac074c
stdio: catch StdioError in dispatch.run and clean up appropriately

We attempt to report what went wrong, and more importantly exit the
program with an error code.

(The exception we catch is not yet raised anywhere in the code.)

diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
--- a/mercurial/dispatch.py
+++ b/mercurial/dispatch.py
@@ -77,7 +77,22 @@ class request(object):
 
 def run():
 "run the command in sys.argv"
-sys.exit((dispatch(request(pycompat.sysargv[1:])) or 0) & 255)
+req = request(pycompat.sysargv[1:])
+err = None
+try:
+status = (dispatch(req) or 0) & 255
+except error.StdioError as err:
+status = -1
+if util.safehasattr(req.ui, 'fout'):
+try:
+req.ui.fout.close()
+except IOError as err:
+status = -1
+if util.safehasattr(req.ui, 'ferr'):
+if err is not None and err.errno != errno.EPIPE:
+req.ui.ferr.write('abort: %s\n' % err.strerror)
+req.ui.ferr.close()
+sys.exit(status & 255)
 
 def _getsimilar(symbols, value):
 sim = lambda x: difflib.SequenceMatcher(None, value, x).ratio()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 9 v2] atexit: test failing handlers

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID b35bc05e7a695ed8cdfd809070965ef9ea9266f9
# Parent  f3a5157b39b32245b0bbcb9d7ac3ce7d9cbefde3
atexit: test failing handlers

diff --git a/tests/test-bad-extension.t b/tests/test-bad-extension.t
--- a/tests/test-bad-extension.t
+++ b/tests/test-bad-extension.t
@@ -1,3 +1,31 @@
+ensure that failing ui.atexit handlers report sensibly
+
+  $ cat > $TESTTMP/bailatexit.py < from mercurial import util
+  > def bail():
+  > raise RuntimeError('ui.atexit handler exception')
+  > 
+  > def extsetup(ui):
+  > ui.atexit(bail)
+  > EOF
+  $ hg -q --config extensions.bailatexit=$TESTTMP/bailatexit.py \
+  >  help help
+  hg help [-ecks] [TOPIC]
+  
+  show help for a given topic or a help overview
+  error in exit handlers:
+  Traceback (most recent call last):
+File "*/mercurial/dispatch.py", line *, in _runexithandlers (glob)
+  func(*args, **kwargs)
+File "$TESTTMP/bailatexit.py", line *, in bail (glob)
+  raise RuntimeError('ui.atexit handler exception')
+  RuntimeError: ui.atexit handler exception
+  [255]
+
+  $ rm $TESTTMP/bailatexit.py
+
+another bad extension
+
   $ echo 'raise Exception("bit bucket overflow")' > badext.py
   $ abspathexc=`pwd`/badext.py
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 4 of 9 v2] stdio: add machinery to identify failed stdout/stderr writes

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID a5aa1dfd9afed15c0cd762c4a72e5e0082ac074c
# Parent  c9e44f83b04ad81797891ba63b0fa4d1587880ea
stdio: add machinery to identify failed stdout/stderr writes

Mercurial currently fails to notice failures to write to stdout or
stderr. A correctly functioning command line tool should detect
this and exit with an error code.

To achieve this, we need a little extra plumbing, which we start
adding here.

diff --git a/mercurial/error.py b/mercurial/error.py
--- a/mercurial/error.py
+++ b/mercurial/error.py
@@ -122,6 +122,12 @@ class CapabilityError(RepoError):
 class RequirementError(RepoError):
 """Exception raised if .hg/requires has an unknown entry."""
 
+class StdioError(IOError):
+"""Raised if I/O to stdout or stderr fails"""
+
+def __init__(self, err):
+IOError.__init__(self, err.errno, err.strerror)
+
 class UnsupportedMergeRecords(Abort):
 def __init__(self, recordtypes):
 from .i18n import _
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 9 v2] atexit: switch to home-grown implementation

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID c9e44f83b04ad81797891ba63b0fa4d1587880ea
# Parent  b35bc05e7a695ed8cdfd809070965ef9ea9266f9
atexit: switch to home-grown implementation

diff --git a/contrib/memory.py b/contrib/memory.py
--- a/contrib/memory.py
+++ b/contrib/memory.py
@@ -12,7 +12,6 @@ prints it to ``stderr`` on exit.
 '''
 
 from __future__ import absolute_import
-import atexit
 
 def memusage(ui):
 """Report memory usage of the current process."""
@@ -29,4 +28,4 @@ def memusage(ui):
 for k, v in result.iteritems()]) + "\n")
 
 def extsetup(ui):
-atexit.register(memusage, ui)
+ui.atexit(memusage, ui)
diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
--- a/mercurial/dispatch.py
+++ b/mercurial/dispatch.py
@@ -7,7 +7,6 @@
 
 from __future__ import absolute_import, print_function
 
-import atexit
 import difflib
 import errno
 import getopt
@@ -767,7 +766,7 @@ def _dispatch(req):
 ui.warn(
 _("time: real %.3f secs (user %.3f+%.3f sys %.3f+%.3f)\n") 
%
 (t[4]-s[4], t[0]-s[0], t[2]-s[2], t[1]-s[1], t[3]-s[3]))
-atexit.register(print_time)
+ui.atexit(print_time)
 
 if options['verbose'] or options['debug'] or options['quiet']:
 for opt in ('verbose', 'debug', 'quiet'):
diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -7,7 +7,6 @@
 
 from __future__ import absolute_import
 
-import atexit
 import collections
 import contextlib
 import errno
@@ -931,7 +930,7 @@ class ui(object):
 if self._isatty(util.stderr):
 os.dup2(pager.stdin.fileno(), util.stderr.fileno())
 
-@atexit.register
+@self.atexit
 def killpager():
 if util.safehasattr(signal, "SIGINT"):
 signal.signal(signal.SIGINT, signal.SIG_IGN)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 9 v2] ui: add special-purpose atexit functionality

[Bryan O'Sullivan]

# HG changeset patch
# User Bryan O'Sullivan 
# Date 1491947652 25200
#  Tue Apr 11 14:54:12 2017 -0700
# Node ID f3a5157b39b32245b0bbcb9d7ac3ce7d9cbefde3
# Parent  e0dc40530c5aa514feb6a09cf79ab6a3aa2ec331
ui: add special-purpose atexit functionality

In spite of its longstanding use, Python's built-in atexit code is
not suitable for Mercurial's purposes, for several reasons:

* Handlers run after application code has finished.

* Because of this, the code that runs handlers swallows exceptions
  (since there's no possible stacktrace to associate errors with).
  If we're lucky, we'll get something spat out to stderr (if stderr
  still works), which of course isn't any use in a big deployment
  where it's important that exceptions get logged and aggregated.

* Mercurial's current atexit handlers make unfortunate assumptions
  about process state (specifically stdio) that, coupled with the
  above problems, make it impossible to deal with certain categories
  of error (try "hg status > /dev/full" on a Linux box).

* In Python 3, the atexit implementation is completely hidden, so
  we can't hijack the platform's atexit code to run handlers at a
  time of our choosing.

As a result, here's a perfectly cromulent atexit-like implementation
over which we have control.  This lets us decide exactly when the
handlers run (after each request has completed), and control what
the process state is when that occurs (and afterwards).

diff --git a/mercurial/dispatch.py b/mercurial/dispatch.py
--- a/mercurial/dispatch.py
+++ b/mercurial/dispatch.py
@@ -59,6 +59,23 @@ class request(object):
 self.fout = fout
 self.ferr = ferr
 
+def _runexithandlers(self):
+exc = None
+handlers = self.ui._exithandlers
+try:
+while handlers:
+func, args, kwargs = handlers.pop()
+try:
+func(*args, **kwargs)
+except: # re-raises below
+if exc is None:
+exc = sys.exc_info()[1]
+self.ui.warn(('error in exit handlers:\n'))
+self.ui.traceback(force=True)
+finally:
+if exc is not None:
+raise exc
+
 def run():
 "run the command in sys.argv"
 sys.exit((dispatch(request(pycompat.sysargv[1:])) or 0) & 255)
@@ -146,6 +163,10 @@ def dispatch(req):
 req.ui.log('uiblocked', 'ui blocked ms', **req.ui._blockedtimes)
 req.ui.log("commandfinish", "%s exited %s after %0.2f seconds\n",
msg, ret or 0, duration)
+try:
+req._runexithandlers()
+except: # exiting, so no re-raises
+ret = ret or -1
 return ret
 
 def _runcatch(req):
diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -139,6 +139,8 @@ class ui(object):
 """
 # _buffers: used for temporary capture of output
 self._buffers = []
+# _exithandlers: callbacks run at the end of a request
+self._exithandlers = []
 # 3-tuple describing how each buffer in the stack behaves.
 # Values are (capture stderr, capture subprocesses, apply labels).
 self._bufferstates = []
@@ -163,6 +165,7 @@ class ui(object):
 self._styles = {}
 
 if src:
+self._exithandlers = src._exithandlers
 self.fout = src.fout
 self.ferr = src.ferr
 self.fin = src.fin
@@ -940,6 +943,13 @@ class ui(object):
 
 return True
 
+def atexit(self, func, *args, **kwargs):
+'''register a function to run after dispatching a request
+
+Handlers do not stay registered across request boundaries.'''
+self._exithandlers.append((func, args, kwargs))
+return func
+
 def interface(self, feature):
 """what interface to use for interactive console features?
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5537] New: email and pager interact strangely

[mercurial-bugs]

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

Bug ID: 5537
   Summary: email and pager interact strangely
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: bug
  Priority: wish
 Component: pager
  Assignee: bugzi...@mercurial-scm.org
  Reporter: b...@serpentine.com
CC: mercurial-devel@mercurial-scm.org

Until recently, hg email -n used to run every email through a separate pager
process. This has changed, such that now all output goes through a single
invocation of the pager, and I have to carefully scan to find the boundaries of
messages instead of bouncing on the q key a few times.

It's arguably not important enough to be worth fixing, but I suspect it was an
accidental regression.

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

Re: stable ordering of test output

[Matt Harbison]

On Thu, 13 Apr 2017 16:17:34 -0400, 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.


This fixes it for Windows too.  Thanks!


# HG changeset patch
# User Augie Fackler 
# Date 1492114180 14400
#  Thu Apr 13 16:09:40 2017 -0400
# Node ID ec81fd7580f3e31aa92e8834ffbcf2a8e80e72e3
# Parent  35afb54dbb4df2975dbbf0e1525b98611f18ba85
sshpeer: try harder to snag stderr when stdout closes unexpectedly

Resolves test failures on FreeBSD, but I'm not happy about the fix.

diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py
--- a/mercurial/sshpeer.py
+++ b/mercurial/sshpeer.py
@@ -110,9 +110,17 @@ class doublepipe(object):
 if mainready:
 meth = getattr(self._main, methname)
 if data is None:
-return meth()
+r = meth()
 else:
-return meth(data)
+r = meth(data)
+if not r and data != 0:
+# We've observed a condition that indicates the
+# stdout closed unexpectedly. Check stderr one
+# more time and snag anything that's there before
+# letting anyone know the main part of the pipe
+# closed prematurely.
+_forwardoutput(self._ui, self._side)
+return r

 def close(self):
 return self._main.close()
___
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: Hidden Commits in 4.3

[Durham Goode]

On 4/13/17 2:43 PM, Pierre-Yves David wrote:



On 04/13/2017 11:37 PM, Pierre-Yves David wrote:

On 04/12/2017 04:23 PM, Ryan McElroy wrote:

I think the next step is for the community to officially figure out
if this is a good direction to go in, however that happens.


I had productive face to face discussion with multiple people in the
past couple a day.  Let us put all technical details aside and look at
the situation at the high level.

The current tentacular discussions are the *gathering of three
different goals*:


There a was a secondary point I wanted to make. But I did not wanted to
inflate the the size of the previous email too much.

The recent discussion *mixes multiple complex topics*. Complex both at
the technical and UI level. It results in a *back and forth of
interleaved discussion* *with people caring about different aspects*.

As a good symptom of that, I've read maybe 3 summaries of the situation
and existing consensus by three different people in the last 48h. To me
they seems to reach sightly different conclusions and outline different
consensus. I'm not even sure how to interpret some ambiguity in them.

After discussion this further with Gregory, I think *we really needs to
introduce more focus this discussion*. I know everybody are itching to
bring up some topics, but we should agree on what is the *next most
important small step we can take and focus on that*. Without trying to
alter other aspects in the same go. Having a*small group of neutral
moderators* to lead the discussion would help.

From the current state of the discussion, I think we should starts with
a *restricted discussion about an alternative to strip*, /mutually
exclusive with evolution/. I personally though local-hiding and
obsolescence hiding could coexist until I read Gregory email. He seems
to be raising valid concerns there.  When that topic is sorted out, we
can move the discussion to something else, for example how they could
coexist.

What do you think?



If we delete the "Interaction With Obsmarkers" paragraph of my proposal, 
it's effectively a proposal for an alternative to strip. Would that be 
an appropriate starting place for a alternative-to-strip discussion?  We 
could leave out it's interaction with evolve for now.

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

Re: Hidden Commits in 4.3

[Durham Goode]

On 4/13/17 2:37 PM, Pierre-Yves David wrote:

On 04/12/2017 04:23 PM, Ryan McElroy wrote:

I think the next step is for the community to officially figure out if
this is a good direction to go in, however that happens.


I had productive face to face discussion with multiple people in the
past couple a day.  Let us put all technical details aside and look at
the situation at the high level.

The current tentacular discussions are the *gathering of three different
goals*:

 * *upstreaming* more of Facebook work (yeah!),
 * *completing changeset evolution* and shipping it to all users,
 * *shipping improvement to users* sooner than later.

All these goals are *important, good, realistic *and*compatible* if done
carefully.
They interact with each others, so we have to make sure we *achieves
each goal without blocking the others*. Something not guaranteed so far
in the current discussions.

So what is our way forward in practice? After discussions with Ryan,
Siddharth and Gregory, I think *we could use the  following principle*:

   When If *someone raise concerns* about the impact of a feature on
   other goals, get the feature in, but *keep it under a config flag
   while we resolve the situation* in one of the following ways:

 * more thinking *lift the concerns*,
 * a *small variant* that can be on by default is introduced,
 * an *equivalent, alternative featured be *on by default in added,
 * an alternative path to the concepts is found that.

As a result:

 * *Facebook can upstream and share code* more easily. Having to live
   with a config knob for a while is not a big deal for them,
 * The surface on which we guarantee backward compatibility *leaves the
   path to complete changeset-evolution open*,
 * In many cases, *community can take advantage of the upstreamed code*
   to offer better capability to the user with just an extra bit of
   code to implement a small variant,
 * As a bonus we can experiment with alternative path and get data
   about them.


I'm happy to introduce the initial version of this under a config flag.

However, I think this just means we delay having this same discussion to 
a later date. And it's not clear how having that config flag for some 
time will improve people's understanding to make the discussion more 
productive (since presumably the community isn't using the flag).



*Practical example* (/simplified/):

   Situation:

 * Facebook has a useful: hg undo command.
 * Facebook cares about hg undo, preserving the hash,
 * this hash preservation conflict with current constraint of
   changeset-evolution.

   Way forward:

 * Facebook can upstream hg undo with hash preservation,
 * We introduces a variant that changes the hash and makes it
   available to all users with BC,
 * Facebook can set the config for hash preservation internally.

   Result: the code is upstream, user has new feature and we can
   discuss hash preservation later.


I think this example is missing the step where we discuss what we should 
ship to users. My goal is not to enable Facebook to have a feature (we 
already have these features), my goal is to create a good user 
experience for Mercurial users. If we do the config knob route, we must 
at some point have the discussion about what experience we want to give 
to users, before we actually ship it to them.


So in your proposal, when will it become appropriate to have that 
discussion? And what can we do between now and then to make that 
discussion more productive? I think we're blocked on getting bits into 
the hands of users by default until then.

___
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: Hidden Commits in 4.3

[Pierre-Yves David]

On 04/13/2017 11:37 PM, Pierre-Yves David wrote:

On 04/12/2017 04:23 PM, Ryan McElroy wrote:
I think the next step is for the community to officially figure out 
if this is a good direction to go in, however that happens.


I had productive face to face discussion with multiple people in the 
past couple a day.  Let us put all technical details aside and look at 
the situation at the high level.


The current tentacular discussions are the *gathering of three 
different goals*:


There a was a secondary point I wanted to make. But I did not wanted to 
inflate the the size of the previous email too much.


The recent discussion *mixes multiple complex topics*. Complex both at 
the technical and UI level. It results in a *back and forth of 
interleaved discussion* *with people caring about different aspects*.


As a good symptom of that, I've read maybe 3 summaries of the situation 
and existing consensus by three different people in the last 48h. To me 
they seems to reach sightly different conclusions and outline different 
consensus. I'm not even sure how to interpret some ambiguity in them.


After discussion this further with Gregory, I think *we really needs to 
introduce more focus this discussion*. I know everybody are itching to 
bring up some topics, but we should agree on what is the *next most 
important small step we can take and focus on that*. Without trying to 
alter other aspects in the same go. Having a*small group of neutral 
moderators* to lead the discussion would help.


From the current state of the discussion, I think we should starts with 
a *restricted discussion about an alternative to strip*, /mutually 
exclusive with evolution/. I personally though local-hiding and 
obsolescence hiding could coexist until I read Gregory email. He seems 
to be raising valid concerns there.  When that topic is sorted out, we 
can move the discussion to something else, for example how they could 
coexist.


What do you think?

--
Pierre-Yves David

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

Re: Hidden Commits in 4.3

[Pierre-Yves David]

On 04/12/2017 04:23 PM, Ryan McElroy wrote:
I think the next step is for the community to officially figure out if 
this is a good direction to go in, however that happens.


I had productive face to face discussion with multiple people in the 
past couple a day.  Let us put all technical details aside and look at 
the situation at the high level.


The current tentacular discussions are the *gathering of three different 
goals*:


 * *upstreaming* more of Facebook work (yeah!),
 * *completing changeset evolution* and shipping it to all users,
 * *shipping improvement to users* sooner than later.

All these goals are *important, good, realistic *and*compatible* if done 
carefully.
They interact with each others, so we have to make sure we *achieves 
each goal without blocking the others*. Something not guaranteed so far 
in the current discussions.


So what is our way forward in practice? After discussions with Ryan, 
Siddharth and Gregory, I think *we could use the  following principle*:


   When If *someone raise concerns* about the impact of a feature on
   other goals, get the feature in, but *keep it under a config flag
   while we resolve the situation* in one of the following ways:

 * more thinking *lift the concerns*,
 * a *small variant* that can be on by default is introduced,
 * an *equivalent, alternative featured be *on by default in added,
 * an alternative path to the concepts is found that.

As a result:

 * *Facebook can upstream and share code* more easily. Having to live
   with a config knob for a while is not a big deal for them,
 * The surface on which we guarantee backward compatibility *leaves the
   path to complete changeset-evolution open*,
 * In many cases, *community can take advantage of the upstreamed code*
   to offer better capability to the user with just an extra bit of
   code to implement a small variant,
 * As a bonus we can experiment with alternative path and get data
   about them.

*Practical example* (/simplified/):

   Situation:

 * Facebook has a useful: hg undo command.
 * Facebook cares about hg undo, preserving the hash,
 * this hash preservation conflict with current constraint of
   changeset-evolution.

   Way forward:

 * Facebook can upstream hg undo with hash preservation,
 * We introduces a variant that changes the hash and makes it
   available to all users with BC,
 * Facebook can set the config for hash preservation internally.

   Result: the code is upstream, user has new feature and we can
   discuss hash preservation later.

--
Pierre-Yves David

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

RE: [PATCH 4 of 4 shelve-ext v3] shelve: make shelvestate use simplekeyvaluefile

[Kostia Balytskyi]

> -Original Message-
> From: Yuya Nishihara [mailto:you...@gmail.com] On Behalf Of Yuya
> Nishihara
> Sent: Thursday, 13 April, 2017 13:47
> To: Kostia Balytskyi 
> Cc: mercurial-devel@mercurial-scm.org
> Subject: Re: [PATCH 4 of 4 shelve-ext v3] shelve: make shelvestate use
> simplekeyvaluefile
> 
> On Wed, 12 Apr 2017 21:34:23 +, Kostia Balytskyi wrote:
> > > -Original Message-
> > > From: Yuya Nishihara [mailto:you...@gmail.com] On Behalf Of Yuya
> > > Nishihara
> > > Sent: Wednesday, 12 April, 2017 16:03
> > > To: Kostia Balytskyi 
> > > Cc: mercurial-devel@mercurial-scm.org
> > > Subject: Re: [PATCH 4 of 4 shelve-ext v3] shelve: make shelvestate
> > > use simplekeyvaluefile
> > >
> > > On Mon, 10 Apr 2017 16:28:36 -0700, Kostia Balytskyi wrote:
> > > > # HG changeset patch
> > > > # User Kostia Balytskyi  # Date 1491866434 25200
> > > > #  Mon Apr 10 16:20:34 2017 -0700
> > > > # Node ID 8e286a85816581cfa4ce44768482cb5722a88bb3
> > > > # Parent  961539160565df5052d1c770788cacb2d76e9752
> > > > shelve: make shelvestate use simplekeyvaluefile
> > > >
> > > > Currently shelvestate uses line ordering to differentiate fields.
> > > > This makes it hard for extensions to wrap shelve, since if two
> > > > alternative versions of code add a new line, correct merging is going to
> be problematic.
> > > > simplekeyvaluefile was introduced fot this purpose specifically.
> > > >
> > > > After this patch:
> > > > - shelve will always write a simplekeyvaluefile, unless
> 'shelve.oldstatefile'
> > > > is on
> > > > - unshelve will check the first line of the file and if it has '='
> > > > sign, will treat the file as a simplekeyvalue one. Otherwise, it
> > > > will try to read an old-style statefile.
> > > >
> > > > Test change is needed, because just a few lines below the place of
> > > > change, test script does a direct manipulation of shelvestate file
> > > > by removing a line in a particular position. Clearly, this relies
> > > > on the fact that the file is  is position-based, not key-value.
> > > >
> > > > diff --git a/hgext/shelve.py b/hgext/shelve.py
> > > > --- a/hgext/shelve.py
> > > > +++ b/hgext/shelve.py
> > > > @@ -166,6 +166,10 @@ class shelvedstate(object):
> > > >
> > > >  Handles saving and restoring a shelved state. Ensures that 
> > > > different
> > > >  versions of a shelved state are possible and handles them
> appropriately.
> > > > +
> > > > +By default, simplekeyvaluefile is used. The following config option
> > > > +allows one to enforce the old position-based state file to be used:
> > > > +shelve.oldstatefile
> > > >  """
> > > >  _version = 1
> > >
> > > I think this is the version 2 of the state file.
> > >
> > > And I don't think the config knob is good way to support old state
> > > file. If we want to support writing old state files, we can write
> > > two separate files, like mergestate. If not, we only need to switch
> > > parsers depending on the version field, like histedit.
> >
> > The idea behind this was that old state files should almost never be
> written. And I can't really think of any reason we would want to write them,
> except for that one test, which can be adjusted.
> 
> Then, how about adding undocumented 'debug.' config for
> testing purpose?
Test can be rewritten to work with key-value file, it's not a problem.
> 
> > > > @@ -175,6 +179,18 @@ class shelvedstate(object):
> > > >  _noactivebook = ':no-active-bookmark'
> > > >
> > > >  @classmethod
> > > > +def iskeyvaluebased(cls, repo):
> > > > +"""Determine whether state file is simple lines or
> > > simplekeyvaluefile"""
> > > > +if repo.ui.configbool('shelve', 'oldstatefile', False):
> > > > +return True
> > > > +fp = repo.vfs(cls._filename)
> > > > +try:
> > > > +firstline = fp.readline()
> > > > +return '=' in firstline
> > > > +finally:
> > > > +fp.close()
> > >
> > > Perhaps it's better to compare the version number instead of relying
> > > on heuristic.
> > Comparing versions (if I understand you correctly) wouldn't work, see
> below.
> 
> I couldn't get why new format can't be version 2. The old format had '1\n'
> for future extension. This patch introduces new format, so using '2\n' makes
> sense to me.
> 
> The current simplekeyvaluefile API would make this a bit harder, but we can
> extract functions to serialize and deserialize dict from/to file object.
I do not understand what 'extract functions ...' means in this context? Can you 
explain?
> 
> > > > +@classmethod
> > > >  def load(cls, repo):
> > > >  # Order is important, because old shelvestate file uses it
> > > >  # to detemine values of fields (i.g. version is on the
> > > > first line, @@ -182,12 +198,15 @@ class shelvedstate(object):
> > > >  keys = ['version', 'name', 'originalwctx', 'pendingctx', 
> > > > 

Re: stable ordering of test output

[Augie Fackler]

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.

# HG changeset patch
# User Augie Fackler 
# Date 1492114180 14400
#  Thu Apr 13 16:09:40 2017 -0400
# Node ID ec81fd7580f3e31aa92e8834ffbcf2a8e80e72e3
# Parent  35afb54dbb4df2975dbbf0e1525b98611f18ba85
sshpeer: try harder to snag stderr when stdout closes unexpectedly

Resolves test failures on FreeBSD, but I'm not happy about the fix.

diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py
--- a/mercurial/sshpeer.py
+++ b/mercurial/sshpeer.py
@@ -110,9 +110,17 @@ class doublepipe(object):
 if mainready:
 meth = getattr(self._main, methname)
 if data is None:
-return meth()
+r = meth()
 else:
-return meth(data)
+r = meth(data)
+if not r and data != 0:
+# We've observed a condition that indicates the
+# stdout closed unexpectedly. Check stderr one
+# more time and snag anything that's there before
+# letting anyone know the main part of the pipe
+# closed prematurely.
+_forwardoutput(self._ui, self._side)
+return r

 def close(self):
 return self._main.close()
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] sshpeer: fix docstring typo

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1492109298 14400
#  Thu Apr 13 14:48:18 2017 -0400
# Node ID 35afb54dbb4df2975dbbf0e1525b98611f18ba85
# Parent  f23d579a5a04e44f5e0370ba13ad20dd626e8ad7
sshpeer: fix docstring typo

diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py
--- a/mercurial/sshpeer.py
+++ b/mercurial/sshpeer.py
@@ -62,7 +62,7 @@ class doublepipe(object):
 large read for data not yet emitted by the server.
 
 The main pipe is expected to be a 'bufferedinputpipe' from the util module
-that handle all the os specific bites. This class lives in this module
+that handle all the os specific bits. This class lives in this module
 because it focus on behavior specific to the ssh protocol."""
 
 def __init__(self, ui, main, side):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Hidden Commits in 4.3

[Durham Goode]

On 4/12/17 10:44 PM, Gregory Szorc wrote:


I just read this entire thread and am trying to wrap my head around
different sides of the argument. I clearly see where Durham, Ryan, and
others are coming from with "strip-based operations are bad." I think we
can all agree on that. I can also see how the new hiding mechanism is
effectively the same as strip-based operations in terms of behavior, but
without the poor performance and hacks. So it seems like a generally
good idea.

But I'm having difficulty comprehending Pierre-Yves's opposition to this
seemingly good proposal. Pierre-Yves has thought about evolution
concepts more than anyone, so when he raises an alarm, it is worth
taking the time to listen and understand his concerns so we don't
jeopardize the future of evolve. However, despite the vast amount of
words written, it still isn't clear to me exactly what the main
objection is. But from seeing "global state" and "monotonic" enough
times and reading through https://www.mercurial-scm.org/wiki/CEDConcept
,
I think I have an idea. (Pierre-Yves: please confirm or correct what I'm
about to say.)

I think most of Pierre-Yves's concerns are rooted at a *potential*
intrinsic incompatibility between a) a generic, non-versioned,
non-monotonic hiding mechanism (the proposal) and b) what is essentially
obsolescence markers of today. For example, if the new hiding mechanism
isn't designed with consideration for evolve, evolve/Mercurial would see
an instruction to hide a changeset but evolve would be powerless to make
any kind of reasonable judgement based on the "why" and "how" that
changeset became hidden because that data just isn't recorded. In other
words, generic hiding lacks the "global state" and "monotonic"
properties of the obsolescence store and its exchange, making evolve
less effective. This *would* undermine the ability to ship a high
quality product: so Pierre-Yves isn't using hyperbole when he says he
fears that he could deliver evolve depending on how this hiding feature
is implemented.


I think your analysis is correct. There are trade offs: A completely 
mutable hidden store would hinder certain types of analysis in the 
future. A append-only-obsmarker based hidden would prevent certain types 
of user interactions in the future (ex: unhiding).


I believe optimizing for the 'certain types of analysis' case is 
optimizing for an edge case of an edge case workflow (mutable history 
conflicts within mutable history collaboration) at the expense of the 
common case workflows (local history mutation, commit revival, commit 
hiding mental model, and simple client/server workflows).


In my understanding, the actual user experience impact on evolve of this 
proposal (vs the theory oriented impact) is that *if* the user is doing 
mutable history collaboration, and *if* they have a mutable history 
conflict of some type, and *if* they've messed with visibility 
themselves, *then* evolve would be unable to determine the correct 
result and would have to prompt the user. I might be over simplifying, 
so I agree that concrete examples would help understand the impact of 
this change.


So, in my head having 'hg hide/unhide' be a dead simple, understandable 
(for both users and extensions) primitive in all cases is highly 
desirable, and is worth the trade off.



Regardless of whether this is actually Pierre-Yves's fundamental
concern, there is a conflict here that needs addressed. And I /think/
that conflict can be summarized as "how do we ensure that evolve is the
sole source of truth for hidden/obsolescence data?" Because if evolve
isn't the sole source of truth for hidden/obsolescence data, then evolve
has to essentially guess at what to do with changesets hidden for
"unknown" reasons and that severely undermines the ability of evolve to
work well.


As mentioned above, it only undermines evolve's ability if the user 
actually did manual visibility manipulations. If they didn't, then 
things work exactly as they do today. And the remediation in the failure 
case is to just tell the user "hey, you have to choose between action A 
or action B". This doesn't sound so bad, especially if this prompt is 
going to be part of certain evolve workflows anyway (since there will 
almost certainly exist ambiguous situations in even the most well 
designed evolve world).



What I think this means is that we need writes to a generic hiding
mechanism and evolve/obsolescence markers to be mutually exclusive. I.e.
if obsolescence markers are active, we can't be hiding things via
not-obsolescence-markers because doing so would deprive evolve of
critical knowledge.


We'll want obsmarker data even in a non-evolve world. See my restack 
proposal for how obs information can be useful as 

Re: stable ordering of test output

[Augie Fackler]

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...
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] util: pass sysstrs to warnings.filterwarnings

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1492103569 14400
#  Thu Apr 13 13:12:49 2017 -0400
# Node ID a34b5e7c66830e2f13e4ec32f7abbd64a06a5b8a
# Parent  f23d579a5a04e44f5e0370ba13ad20dd626e8ad7
util: pass sysstrs to warnings.filterwarnings

Un-breaks the Python 3 build.

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -168,9 +168,9 @@ if _dowarn:
 # However, module name set through PYTHONWARNINGS was exactly matched, so
 # we cannot set 'mercurial' and have it match eg: 'mercurial.scmutil'. This
 # makes the whole PYTHONWARNINGS thing useless for our usecase.
-warnings.filterwarnings('default', '', DeprecationWarning, 'mercurial')
-warnings.filterwarnings('default', '', DeprecationWarning, 'hgext')
-warnings.filterwarnings('default', '', DeprecationWarning, 'hgext3rd')
+warnings.filterwarnings(r'default', r'', DeprecationWarning, r'mercurial')
+warnings.filterwarnings(r'default', r'', DeprecationWarning, r'hgext')
+warnings.filterwarnings(r'default', r'', DeprecationWarning, r'hgext3rd')
 
 def nouideprecwarn(msg, version, stacklevel=1):
 """Issue an python native deprecation warning
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 5536] New: [request] `hg log` flag which includes the full commit message (but not the list of files)

[mercurial-bugs]

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

Bug ID: 5536
   Summary: [request] `hg log` flag which includes the full commit
message (but not the list of files)
   Product: Mercurial
   Version: 4.1.2
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alex.gay...@gmail.com
CC: mercurial-devel@mercurial-scm.org

|hg log|'s --verbose flag very helpfully includes the full commit message, but
also includes the list of files changed by the commit, which I don't generally
want (and when I do want it, I use --stat).

It'd be nice to have a new flag which gives me just the full commit messages
(and then I will immediately put this flag in my [defaults]). And yes, I'm
basically trying to emulate git's behavior here.

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

[PATCH V2] pager: set some environment variables if they're not set

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1492097239 25200
#  Thu Apr 13 08:27:19 2017 -0700
# Node ID aec3d224f8955e8956bbb2b7d49c76d410f42e19
# Parent  eaf3819631c206722c7594d8f54ed769a95f54b4
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r aec3d224f895
pager: set some environment variables if they're not set

Git did this already [1] [2]. We want this behavior too [3].

This provides a better default user experience (like, supporting colors) if
users have things like "PAGER=less" set, which is not uncommon.

The environment variables are provided by a method so extensions can
override them on demand.

[1]: 
https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/pager.c#L87
[2]: 
https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/Makefile#L1545
[3]: 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094780.html

diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py
--- a/mercurial/chgserver.py
+++ b/mercurial/chgserver.py
@@ -191,6 +191,6 @@ def _newchgui(srcui, csystem, attachio):
 return self._csystem(cmd, util.shellenviron(environ), cwd)
 
-def _runpager(self, cmd):
-self._csystem(cmd, util.shellenviron(), type='pager',
+def _runpager(self, cmd, env=None):
+self._csystem(cmd, util.shellenviron(env), type='pager',
   cmdtable={'attachio': attachio})
 return True
diff --git a/mercurial/rcutil.py b/mercurial/rcutil.py
--- a/mercurial/rcutil.py
+++ b/mercurial/rcutil.py
@@ -91,2 +91,8 @@ def rccomponents():
 _rccomponents.extend(normpaths(userrcpath()))
 return _rccomponents
+
+def defaultpagerenv():
+'''return a dict of default environment variables and their values,
+intended to be set before starting a pager.
+'''
+return {'LESS': 'FRX', 'LV': '-c'}
diff --git a/mercurial/ui.py b/mercurial/ui.py
--- a/mercurial/ui.py
+++ b/mercurial/ui.py
@@ -855,4 +855,9 @@ class ui(object):
 return
 
+pagerenv = {}
+for name, value in rcutil.defaultpagerenv().items():
+if name not in encoding.environ:
+pagerenv[name] = value
+
 self.debug('starting pager for command %r\n' % command)
 self.flush()
@@ -861,5 +866,5 @@ class ui(object):
 if util.safehasattr(signal, "SIGPIPE"):
 signal.signal(signal.SIGPIPE, _catchterm)
-if self._runpager(pagercmd):
+if self._runpager(pagercmd, pagerenv):
 self.pageractive = True
 # Preserve the formatted-ness of the UI. This is important
@@ -880,5 +885,5 @@ class ui(object):
 self.disablepager()
 
-def _runpager(self, command):
+def _runpager(self, command, env=None):
 """Actually start the pager and set up file descriptors.
 
@@ -913,5 +918,6 @@ class ui(object):
 command, shell=shell, bufsize=-1,
 close_fds=util.closefds, stdin=subprocess.PIPE,
-stdout=util.stdout, stderr=util.stderr)
+stdout=util.stdout, stderr=util.stderr,
+env=util.shellenviron(env))
 except OSError as e:
 if e.errno == errno.ENOENT and not shell:
diff --git a/tests/test-pager.t b/tests/test-pager.t
--- a/tests/test-pager.t
+++ b/tests/test-pager.t
@@ -255,2 +255,28 @@ Put annotate in the ignore list for page
9: a 9
   10: a 10
+
+Environment variables like LESS and LV are set automatically:
+  $ cat > $TESTTMP/printlesslv.py < import os, sys
+  > sys.stdin.read()
+  > for name in ['LESS', 'LV']:
+  > sys.stdout.write(('%s=%s\n') % (name, os.environ.get(name, '-')))
+  > sys.stdout.flush()
+  > EOF
+
+  $ cat >> $HGRCPATH < [alias]
+  > noop = log -r 0 -T ''
+  > [ui]
+  > formatted=1
+  > [pager]
+  > pager = $PYTHON $TESTTMP/printlesslv.py
+  > EOF
+  $ unset LESS
+  $ unset LV
+  $ hg noop --pager=on
+  LESS=FRX
+  LV=-c
+  $ LESS=EFGH hg noop --pager=on
+  LESS=EFGH
+  LV=-c
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 4] revset: add a 'descend' argument to followlines to return descendants

[Yuya Nishihara]

On Tue, 11 Apr 2017 15:09:09 +0200, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde 
> # Date 1484555087 -3600
> #  Mon Jan 16 09:24:47 2017 +0100
> # Node ID 182fa6fb647dcfac8ebcc6a3a6646be43122b2b9
> # Parent  ce5fd23baea30c83d668a8680d2b6ed0ef7baa14
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r 182fa6fb647d
> revset: add a 'descend' argument to followlines to return descendants

> -@predicate('followlines(file, fromline:toline[, startrev=.])', safe=True)
> +@predicate('followlines(file, fromline:toline[, startrev=., descend=False])',
> +   safe=True)
>  def followlines(repo, subset, x):
>  """Changesets modifying `file` in line range ('fromline', 'toline').
>  
>  Line range corresponds to 'file' content at 'startrev' and should hence 
> be
>  consistent with file size. If startrev is not specified, working 
> directory's
>  parent is used.
> +
> +By default, ancestors of 'startrev' are returned. If 'descend' is True,
> +descendants of 'startrev' are returned though renames are (currently) not
> +followed in this direction.
>  """
>  from . import context  # avoid circular import issues
>  
> -args = getargsdict(x, 'followlines', 'file *lines startrev')
> +args = getargsdict(x, 'followlines', 'file *lines startrev descend')
>  if len(args['lines']) != 1:
>  raise error.ParseError(_("followlines requires a line range"))
>  
> @@ -939,9 +944,17 @@ def followlines(repo, subset, x):
>  fromline, toline = util.processlinerange(fromline, toline)
>  
>  fctx = repo[rev].filectx(fname)
> -revs = (c.rev() for c, _linerange
> -in context.blockancestors(fctx, fromline, toline))
> -return subset & generatorset(revs, iterasc=False)
> +if args.get('descend', False):

args['descend'] isn't a boolean but a parsed tree. I'll send a follow up this
weekend.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 4] context: add a blockdescendants function

[Yuya Nishihara]

On Tue, 11 Apr 2017 15:09:08 +0200, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde 
> # Date 1491829896 -7200
> #  Mon Apr 10 15:11:36 2017 +0200
> # Node ID ce5fd23baea30c83d668a8680d2b6ed0ef7baa14
> # Parent  9259cf823690e4fcd34a4d2ecd57ced2060d2b3d
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r ce5fd23baea3
> context: add a blockdescendants function
> 
> This is symmetrical with blockancestors() and yields descendants of a filectx
> with changes in the given line range. The noticeable difference is that the
> algorithm does not follow renames (probably because filelog.descendants() does
> not), so we are missing branches with renames.
> 
> diff --git a/mercurial/context.py b/mercurial/context.py
> --- a/mercurial/context.py
> +++ b/mercurial/context.py
> @@ -1208,6 +1208,26 @@ def blockancestors(fctx, fromline, tolin
>  if inrange:
>  yield c, linerange2
>  
> +def blockdescendants(fctx, fromline, toline):
> +"""Yield descendants of `fctx` with respect to the block of lines within
> +`fromline`-`toline` range.
> +"""
> +diffopts = patch.diffopts(fctx._repo.ui)
> +fl = fctx.filelog()
> +seen = {fctx.filerev(): (fctx, (fromline, toline))}
> +for i in fl.descendants([fctx.filerev()]):
> +c = fctx.filectx(i)
> +for x in fl.parentrevs(i):
> +try:
> +p, linerange2 = seen.pop(x)

Maybe this only follows the first branch? The revision 'x' can have many
children.

> +except KeyError:
> +# nullrev or other branch
> +continue
> +inrange, linerange1 = _changesrange(c, p, linerange2, diffopts)
> +if inrange:
> +yield c, linerange1
> +seen[i] = c, linerange1
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@31919: 15 new changesets

[Mercurial Commits]

15 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/00f5d27dd553
changeset:   31905:00f5d27dd553
user:Pierre-Yves David 
date:Mon Apr 10 16:40:40 2017 +0200
summary: obsolescence: add setup script for obsolescence markers exchange 
tests

https://www.mercurial-scm.org/repo/hg/rev/ae734bd02630
changeset:   31906:ae734bd02630
user:Pierre-Yves David 
date:Mon Apr 10 16:41:21 2017 +0200
summary: obsolescence: add test case A-1 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/fb8c3bc27e87
changeset:   31907:fb8c3bc27e87
user:Pierre-Yves David 
date:Mon Apr 10 16:41:46 2017 +0200
summary: obsolescence: add test case A-2 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/db931f75c374
changeset:   31908:db931f75c374
user:Pierre-Yves David 
date:Mon Apr 10 16:42:49 2017 +0200
summary: obsolescence: add test case A-3 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/df0f18546e1e
changeset:   31909:df0f18546e1e
user:Pierre-Yves David 
date:Mon Apr 10 16:43:26 2017 +0200
summary: obsolescence: add test case A-4 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/46714216541d
changeset:   31910:46714216541d
user:Pierre-Yves David 
date:Mon Apr 10 16:43:49 2017 +0200
summary: obsolescence: add test case A-5 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/7d8b9c80ba70
changeset:   31911:7d8b9c80ba70
user:Pierre-Yves David 
date:Mon Apr 10 16:44:19 2017 +0200
summary: obsolescence: add test case A-6 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/7b829624319f
changeset:   31912:7b829624319f
user:Pierre-Yves David 
date:Mon Apr 10 16:44:39 2017 +0200
summary: obsolescence: add test case A-7 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/850a06176d82
changeset:   31913:850a06176d82
user:Pierre-Yves David 
date:Mon Apr 10 16:46:03 2017 +0200
summary: obsolescence: add test case B-1 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/c8e5370ab4ba
changeset:   31914:c8e5370ab4ba
user:Pierre-Yves David 
date:Mon Apr 10 16:46:31 2017 +0200
summary: obsolescence: add test case B-2 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/ba7e226291f2
changeset:   31915:ba7e226291f2
user:Pierre-Yves David 
date:Mon Apr 10 16:46:53 2017 +0200
summary: obsolescence: add test case B-3 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/4a4fa665e1b4
changeset:   31916:4a4fa665e1b4
user:Pierre-Yves David 
date:Mon Apr 10 16:47:16 2017 +0200
summary: obsolescence: add test case B-4 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/e4d1a7e07761
changeset:   31917:e4d1a7e07761
user:Pierre-Yves David 
date:Mon Apr 10 16:49:10 2017 +0200
summary: obsolescence: add test case B-5 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/68dc2ecabf31
changeset:   31918:68dc2ecabf31
user:Pierre-Yves David 
date:Mon Apr 10 16:49:38 2017 +0200
summary: obsolescence: add test case B-6 for obsolescence markers exchange

https://www.mercurial-scm.org/repo/hg/rev/2bf73e351eb1
changeset:   31919:2bf73e351eb1
bookmark:@
tag: tip
user:Pierre-Yves David 
date:Mon Apr 10 16:50:23 2017 +0200
summary: obsolescence: add test case B-7 for obsolescence markers exchange

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

Re: [PATCH 2 of 2 V3] vfs: deprecate all old classes in scmutil

[Yuya Nishihara]

On Thu, 13 Apr 2017 16:53:32 +0200, Pierre-Yves David wrote:
> # HG changeset patch
> # User Pierre-Yves David 
> # Date 1491222098 -7200
> #  Mon Apr 03 14:21:38 2017 +0200
> # Node ID e92f6389d3f2182864fccc3e4dc4ce7fb70fea7b
> # Parent  a86a1d8576c062dc6a95a7d02c886f9cf798d65e
> # EXP-Topic vfs.cleanup
> # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
> #  hg pull 
> https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r e92f6389d3f2
> vfs: deprecate all old classes in scmutil

Queued, thanks.

>  # compatibility layer since all 'vfs' code moved to 'mercurial.vfs'
>  #
>  # This is hard to instal deprecation warning to this since we do not have
>  # access to a 'ui' object.
> -opener = vfs = vfsmod.vfs
> -filteropener = filtervfs = vfsmod.filtervfs
> -abstractvfs = vfsmod.abstractvfs
> -readonlyvfs = vfsmod.readonlyvfs
> -auditvfs = vfsmod.auditvfs
> +opener = _deprecated('opener', 'vfs', vfsmod.vfs)
> +cfs = _deprecated('vfs', 'vfs', vfsmod.vfs)

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

[PATCH 2 of 2 V3] vfs: deprecate all old classes in scmutil

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1491222098 -7200
#  Mon Apr 03 14:21:38 2017 +0200
# Node ID e92f6389d3f2182864fccc3e4dc4ce7fb70fea7b
# Parent  a86a1d8576c062dc6a95a7d02c886f9cf798d65e
# EXP-Topic vfs.cleanup
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r e92f6389d3f2
vfs: deprecate all old classes in scmutil

Now that all vfs class moved to the vfs module, we can deprecate the old one.

diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -329,15 +329,25 @@ def filteredhash(repo, maxrev):
 key = s.digest()
 return key
 
+def _deprecated(old, new, func):
+msg = ('class at mercurial.scmutil.%s moved to mercurial.vfs.%s'
+   % (old, new))
+def wrapper(*args, **kwargs):
+util.nouideprecwarn(msg, '4.2')
+return func(*args, **kwargs)
+return wrapper
+
 # compatibility layer since all 'vfs' code moved to 'mercurial.vfs'
 #
 # This is hard to instal deprecation warning to this since we do not have
 # access to a 'ui' object.
-opener = vfs = vfsmod.vfs
-filteropener = filtervfs = vfsmod.filtervfs
-abstractvfs = vfsmod.abstractvfs
-readonlyvfs = vfsmod.readonlyvfs
-auditvfs = vfsmod.auditvfs
+opener = _deprecated('opener', 'vfs', vfsmod.vfs)
+cfs = _deprecated('vfs', 'vfs', vfsmod.vfs)
+filteropener = _deprecated('filteropener', 'filtervfs', vfsmod.filtervfs)
+filtervfs = _deprecated('filtervfs', 'filtervfs', vfsmod.filtervfs)
+abstractvfs = _deprecated('abstractvfs', 'abstractvfs', vfsmod.abstractvfs)
+readonlyvfs = _deprecated('readonlyvfs', 'readonlyvfs', vfsmod.readonlyvfs)
+auditvfs = _deprecated('auditvfs', 'auditvfs', vfsmod.auditvfs)
 checkambigatclosing = vfsmod.checkambigatclosing
 
 def walkrepos(path, followsym=False, seen_dirs=None, recurse=False):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 2 V3] util: add a way to issue deprecation warning without a UI object

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1491296609 -7200
#  Tue Apr 04 11:03:29 2017 +0200
# Node ID a86a1d8576c062dc6a95a7d02c886f9cf798d65e
# Parent  2bf73e351eb1bb086e30c9f58543817fb05e558c
# EXP-Topic vfs.cleanup
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r a86a1d8576c0
util: add a way to issue deprecation warning without a UI object

Our current deprecation warning mechanism rely on ui object. They are case where
we cannot have access to the UI object. On a general basis we avoid using the
python mechanism for deprecation warning because up to Python 2.6 it is exposing
warning to unsuspecting user who cannot do anything to deal with them.

So we build a "safe" strategy to hide this warnings behind a flag in an
environment variable. The test runner set this flag so that tests show these
warning.  This will help us marker API as deprecated for extensions to update
their code.

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -38,6 +38,7 @@ import tempfile
 import textwrap
 import time
 import traceback
+import warnings
 import zlib
 
 from . import (
@@ -155,6 +156,31 @@ def bitsfrom(container):
 bits |= bit
 return bits
 
+# python 2.6 still have deprecation warning enabled by default. We do not want
+# to display anything to standard user so detect if we are running test and
+# only use python deprecation warning in this case.
+_dowarn = bool(encoding.environ.get('HGEMITWARNINGS'))
+if _dowarn:
+# explicitly unfilter our warning for python 2.7
+#
+# The option of setting PYTHONWARNINGS in the test runner was investigated.
+# However, module name set through PYTHONWARNINGS was exactly matched, so
+# we cannot set 'mercurial' and have it match eg: 'mercurial.scmutil'. This
+# makes the whole PYTHONWARNINGS thing useless for our usecase.
+warnings.filterwarnings('default', '', DeprecationWarning, 'mercurial')
+warnings.filterwarnings('default', '', DeprecationWarning, 'hgext')
+warnings.filterwarnings('default', '', DeprecationWarning, 'hgext3rd')
+
+def nouideprecwarn(msg, version, stacklevel=1):
+"""Issue an python native deprecation warning
+
+This is a noop outside of tests, use 'ui.deprecwarn' when possible.
+"""
+if _dowarn:
+msg += ("\n(compatibility will be dropped after Mercurial-%s,"
+" update your code.)") % version
+warnings.warn(msg, DeprecationWarning, stacklevel + 1)
+
 DIGESTS = {
 'md5': hashlib.md5,
 'sha1': hashlib.sha1,
diff --git a/tests/run-tests.py b/tests/run-tests.py
--- a/tests/run-tests.py
+++ b/tests/run-tests.py
@@ -884,6 +884,7 @@ class Test(unittest.TestCase):
 env = os.environ.copy()
 if sysconfig is not None:
 env['PYTHONUSERBASE'] = sysconfig.get_config_var('userbase')
+env['HGEMITWARNINGS'] = '1'
 env['TESTTMP'] = self._testtmp
 env['HOME'] = self._testtmp
 # This number should match portneeded in _getport
diff --git a/tests/test-devel-warnings.t b/tests/test-devel-warnings.t
--- a/tests/test-devel-warnings.t
+++ b/tests/test-devel-warnings.t
@@ -3,7 +3,7 @@
   > """A small extension that tests our developer warnings
   > """
   > 
-  > from mercurial import cmdutil, repair
+  > from mercurial import cmdutil, repair, util
   > 
   > cmdtable = {}
   > command = cmdutil.command(cmdtable)
@@ -58,6 +58,9 @@
   > def foobar(ui):
   > ui.deprecwarn('foorbar is deprecated, go shopping', '42.1337')
   > foobar(ui)
+  > @command('nouiwarning', [], '')
+  > def nouiwarning(ui, repo):
+  > util.nouideprecwarn('this is a test', '13.37')
   > EOF
 
   $ cat << EOF >> $HGRCPATH
@@ -163,4 +166,15 @@ Test programming error failure:
   Traceback (most recent call last):
   mercurial.error.ProgrammingError: transaction requires locking
 
+Old style deprecation warning
+
+  $ hg nouiwarning
+  $TESTTMP/buggylocking.py:61: DeprecationWarning: this is a test
+  (compatibility will be dropped after Mercurial-13.37, update your code.)
+util.nouideprecwarn('this is a test', '13.37')
+
+(disabled outside of test run)
+
+  $ HGEMITWARNINGS= hg nouiwarning
+
   $ cd ..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2 V2] util: add a way to issue deprecation warning without a UI object

[Pierre-Yves David]

On 04/13/2017 02:07 PM, Yuya Nishihara wrote:

On Thu, 13 Apr 2017 01:14:48 +0200, Pierre-Yves David wrote:



On 04/10/2017 04:35 PM, Yuya Nishihara wrote:

On Mon, 10 Apr 2017 15:41:08 +0200, Pierre-Yves David wrote:

On 04/09/2017 03:08 PM, Yuya Nishihara wrote:

On Sat, 8 Apr 2017 11:37:20 +0200, Pierre-Yves David wrote:

On 04/08/2017 10:16 AM, Yuya Nishihara wrote:

On Fri, 7 Apr 2017 19:03:55 +0200, Pierre-Yves David wrote:

On 04/06/2017 05:44 PM, Yuya Nishihara wrote:

On Thu, 6 Apr 2017 16:09:07 +0200, Pierre-Yves David wrote:

If dirty hack allowed, I would do something like the following:

  # util.py
  def _deprecwarn(msg, version):
  pass

  # somewhere ui is available, maybe in dispatch.py
  util._deprecwarn = ui.deprecwarn


That is a diry hack. I would prefer we did not used it.


Yeah, that is dirty and I don't like it. But I'm okay with it as long as
it is a temporary hack.


If you think the dirty hack is worth the potential extra exposure, I'm
fine with it.

However, I'm confused about your usage of "temporary hack" here. Why are
you using temporary?


I suppose the hack will hopefully disappear with the vfs compat layer. I'm not
sure if a permanent one is necessary.


I think this kind of needs will appears again in the future. So I would
not flag the solution as temporary. I would have made the function local
to the scmutil module.

So I would rather have a long terms solution. What do you think?


If we need less ad-hoc one, I would add a global flag to enable deprecwarn
and set it only by global configuration (i.e. ui, not lui nor repo.ui.)


This seems a bit hacky (I also have some concerns about possible of
deprecated function being created before the ui is. but I'm not sure
they are funded).


IMHO it's as bad as using environment variable. Both are a kind of globals.


The global assignment possibly keeps an object alive longer than its due
time. So I find it a bit hackier.


That's why I proposed a global boolean flag as an alternative.


ha!, I somehow missed that proposal when reading you. That seems 
interesting. If I get back to this area, I'll investigate possible 
timing issue play with that approach





And perhaps will remove ui.deprecwarn() in favor of util.deprecwarn().


ui.deprecwarn is much more configurable and manageable that the global
one (based on Python deprec warning). I do not think we should drop
`ui.deprecwarc` in favor of the other one.


It's more configurable, but less easy to use because ui is required.

Anyway, I don't think it's worth spending time for designing the deprecwarn
feature. I'm okay for any of the ideas in this thread.


This the current series is right here and implemented. Are you okay with
moving forward with it?


Sure. Can you rebase these on tip? The first patch couldn't apply.


Okay, V4 incoming soon.

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

[PATCH 06 of 17] obsolescence: add test for the "branch replacement" logic during push, case A5

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093497 -7200
#  Thu Apr 13 16:24:57 2017 +0200
# Node ID aa51e7b4eb2be8f728c5c12fae72d4e7163d17f1
# Parent  28f833e962f797924e599da54c06ecf01a37a802
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r aa51e7b4eb2b
obsolescence: add test for the "branch replacement" logic during push, case A5

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A5.t 
b/tests/test-push-checkheads-superceed-A5.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A5.t
@@ -0,0 +1,75 @@
+
+Testing head checking code: Case A-5
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 5: New changeset as parent of the successor
+
+.. old-state:
+..
+.. * 1-changeset branch
+..
+.. new-state:
+..
+.. * 2rchangeset branch, head is a successor, but other is new
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   A ø⇠◔ A'
+.. | |
+.. | ◔ B
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A5
+  $ cd A5
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B0
+  created new head
+  $ mkcommit A1
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg log -G --hidden
+  @  ba93660aff8d (draft): A1
+  |
+  o  74ff5441d343 (draft): B0
+  |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A5/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  1 new obsolescence markers
+
+  $ cd ../..
+
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 15 of 17] obsolescence: add test for the "branch replacement" logic during push, case D2

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093662 -7200
#  Thu Apr 13 16:27:42 2017 +0200
# Node ID 0469fdd2e5cc9d0c5c72245cd2dd2daa63f3b388
# Parent  77f468948bb7c9eea215d7447fd379042d760f37
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 0469fdd2e5cc
obsolescence: add test for the "branch replacement" logic during push, case D2

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-unpushed-D2.t 
b/tests/test-push-checkheads-unpushed-D2.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-unpushed-D2.t
@@ -0,0 +1,93 @@
+
+Testing head checking code: Case D-2
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category D: remote head is "obs-affected" locally, but result is not part of 
the push
+TestCase 1: remote branch has 2 changes, head is pruned, other is rewritten 
but result is not pushed
+
+.. old-state:
+..
+.. * 1 changeset branch
+..
+.. new-state:
+..
+.. * old head is pruned
+.. * 1 new branch succeeding to the other changeset in the old branch
+.. * 1 new unrelated branch
+..
+.. expected-result:
+..
+.. * push allowed
+.. * pushing only the unrelated branch: denied
+..
+.. graph-summary:
+..
+..   B ⊗
+.. |
+..   A ø⇠○ A'
+.. |/
+.. | ◔ C
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir D2
+  $ cd D2
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/D2/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete --record-parents `getid "desc(B0)"`
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ hg log -G --hidden
+  @  0f88766e02d6 (draft): C0
+  |
+  | o  f6082bc4ffef (draft): A1
+  |/
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push --rev 'desc(C0)'
+  pushing to $TESTTMP/D2/server (glob)
+  searching for changes
+  abort: push creates new remote head 0f88766e02d6!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 02 of 17] obsolescence: add test for the "branch replacement" logic during push, case A1

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093366 -7200
#  Thu Apr 13 16:22:46 2017 +0200
# Node ID 333e1a68d81e20aaed1569cf1749b0028b294efb
# Parent  dabd8890b002c3cf3ae59526a956404b381e6d3e
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 333e1a68d81e
obsolescence: add test for the "branch replacement" logic during push, case A1

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test case.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A1.t 
b/tests/test-push-checkheads-superceed-A1.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A1.t
@@ -0,0 +1,69 @@
+
+Testing head checking code: Case A-1
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 1: single-changeset branch
+
+.. old-state:
+..
+.. * 1 changeset branch
+..
+.. new-state:
+..
+.. * 1 changeset branch succeeding to A
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   A ø⇠◔ A'
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A1
+  $ cd A1
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg log -G --hidden
+  @  f6082bc4ffef (draft): A1
+  |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A1/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files (+1 heads)
+  1 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 08 of 17] obsolescence: add test for the "branch replacement" logic during push, case A7

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093526 -7200
#  Thu Apr 13 16:25:26 2017 +0200
# Node ID 17791b0c8d8446ad8f59352beb2975823d7c2f3e
# Parent  8945cea7790124a5d1b297770464f7ddf42d08f2
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 17791b0c8d84
obsolescence: add test for the "branch replacement" logic during push, case A7

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A7.t 
b/tests/test-push-checkheads-superceed-A7.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A7.t
@@ -0,0 +1,98 @@
+
+Testing head checking code: Case A-7
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 7: multi-changeset branch, split on multiple other, (head on its own 
branch), same number of head
+
+.. old-state:
+..
+.. * 2 branch (1-changeset, and 2-changesets)
+..
+.. new-state:
+..
+.. * 1 new branch superceeding the head of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superceeding the base of 
the other
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   B ø⇠◔ B'
+.. | |
+.. A'◔⇢ø |
+..   | |/
+.. C ● |
+..\|
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A7
+  $ cd A7
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ hg up 0
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/A7/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  (run 'hg heads' to see heads, 'hg merge' to merge)
+  $ hg up 'desc(C0)'
+  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  $ hg up 0
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  $ mkcommit B1
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete `getid "desc(B0)" ` `getid "desc(B1)"`
+  $ hg log -G --hidden
+  @  25c56d33e4c4 (draft): B1
+  |
+  | o  a0802eb7fc1b (draft): A1
+  | |
+  | o  0f88766e02d6 (draft): C0
+  |/
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A7/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  2 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 10 of 17] obsolescence: add test for the "branch replacement" logic during push, case B3

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093559 -7200
#  Thu Apr 13 16:25:59 2017 +0200
# Node ID eac660902cf1f4f066806b88e73f9d3f8f13e1a0
# Parent  411996b34422a3ae5de800082406502df7e9c0cb
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r eac660902cf1
obsolescence: add test for the "branch replacement" logic during push, case B3

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-pruned-B3.t 
b/tests/test-push-checkheads-pruned-B3.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-pruned-B3.t
@@ -0,0 +1,86 @@
+
+Testing head checking code: Case B-3
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category B: simple case involving pruned changesets
+TestCase 3: multi-changeset branch, other is pruned, rest is superceeded
+
+.. old-state:
+..
+.. * 2 changeset branch
+..
+.. new-state:
+..
+.. * old head is superceeded
+.. * old other is pruned
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   B ø⇠◔ B'
+.. | |
+..   A ⊗ |
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir B3
+  $ cd B3
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/B3/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B1
+  created new head
+  $ hg debugobsolete --record-parents `getid "desc(A0)"`
+  $ hg debugobsolete `getid "desc(B0)" ` `getid "desc(B1)"`
+  $ hg log -G --hidden
+  @  25c56d33e4c4 (draft): B1
+  |
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/B3/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files (+1 heads)
+  2 new obsolescence markers
+
+  $ cd ../..
+
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 11 of 17] obsolescence: add test for the "branch replacement" logic during push, case C2

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093597 -7200
#  Thu Apr 13 16:26:37 2017 +0200
# Node ID 90e43b820d4b79a7a1656acabd587d0554a9478e
# Parent  eac660902cf1f4f066806b88e73f9d3f8f13e1a0
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 90e43b820d4b
obsolescence: add test for the "branch replacement" logic during push, case C2

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-partial-C2.t 
b/tests/test-push-checkheads-partial-C2.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-partial-C2.t
@@ -0,0 +1,82 @@
+
+Testing head checking code: Case C-2
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category C: case were the branch is only partially obsoleted
+TestCase 2: 2 changeset branch, only the base is rewritten
+
+.. old-state:
+..
+.. * 2 changeset branch
+..
+.. new-state:
+..
+.. * 1 new changesets branches superceeding only the base of the old one
+.. * The old branch is still alive (base is obsolete, head is alive)
+..
+.. expected-result:
+..
+.. * push denied
+..
+.. graph-summary:
+..
+..   B ○
+.. |
+..   A ø⇠◔ A'
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir C2
+  $ cd C2
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/C2/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg log -G --hidden
+  @  f6082bc4ffef (draft): A1
+  |
+  | o  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push --rev 'desc(A1)'
+  pushing to $TESTTMP/C2/server (glob)
+  searching for changes
+  abort: push creates new remote head f6082bc4ffef!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 16 of 17] obsolescence: add test dor the "branch replacement" logic during push, case D4

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093674 -7200
#  Thu Apr 13 16:27:54 2017 +0200
# Node ID 6020bb1b76c86bf0b42b174c3348f98e5909e0b2
# Parent  0469fdd2e5cc9d0c5c72245cd2dd2daa63f3b388
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 6020bb1b76c8
obsolescence: add test dor the "branch replacement" logic during push, case D4

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-unpushed-D4.t 
b/tests/test-push-checkheads-unpushed-D4.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-unpushed-D4.t
@@ -0,0 +1,122 @@
+
+Testing head checking code: Case D-4
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category D: remote head is "obs-affected" locally, but result is not part of 
the push
+TestCase 4: multi-changeset branch, split on multiple other, (base on its own 
new branch)
+
+.. old-state:
+..
+.. * 2 branch (1 changeset, and 2 changesets)
+..
+.. new-state:
+..
+.. * 1 new branch superceeding the base of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superceeding the head of 
the other
+..
+.. expected-result:
+..
+.. * push the new branch only -> push denied (variant a)
+.. * push the existing branch only -> push allowed (variant b)
+.. (pushing all is tested as case A-7)
+..
+.. graph-summary:
+..
+.. (variant a)
+..
+.. B'○⇢ø B
+..   | |
+.. A | ø⇠◔ A'
+..   | |/
+.. C ● |
+..\|
+.. ●
+..
+.. or (variant b)
+..
+.. B'◔⇢ø B
+..   | |
+.. A | ø⇠○ A'
+..   | |/
+.. C ● |
+..\|
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir D4
+  $ cd D4
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ hg up 0
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/D4/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  (run 'hg heads' to see heads, 'hg merge' to merge)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg up 'desc(C0)'
+  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B1
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete `getid "desc(B0)" ` `getid "desc(B1)"`
+  $ hg log -G --hidden
+  @  d70a1f75a020 (draft): B1
+  |
+  | o  f6082bc4ffef (draft): A1
+  | |
+  o |  0f88766e02d6 (draft): C0
+  |/
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing (new branch only)
+
+
+  $ hg push --rev 'desc(A1)'
+  pushing to $TESTTMP/D4/server (glob)
+  searching for changes
+  abort: push creates new remote head f6082bc4ffef!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+Actual testing (existing branch only)
+
+
+  $ hg push --rev 'desc(B1)'
+  pushing to $TESTTMP/D4/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  1 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 17 of 17] obsolescence: add test for the "branch replacement" logic during push, case D6

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093695 -7200
#  Thu Apr 13 16:28:15 2017 +0200
# Node ID d106f22c0f397303727ce045698076a3dc4474ba
# Parent  6020bb1b76c86bf0b42b174c3348f98e5909e0b2
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r d106f22c0f39
obsolescence: add test for the "branch replacement" logic during push, case D6

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-unpushed-D6.t 
b/tests/test-push-checkheads-unpushed-D6.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-unpushed-D6.t
@@ -0,0 +1,82 @@
+
+Testing head checking code: Case D-6
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category D: remote head is "obs-affected" locally, but result is not part of 
the push
+TestCase 6: single changeset, superseeded then pruned (on a new changeset 
unpushed) changeset
+
+This is a partial push variation of case B-6
+
+.. old-state:
+..
+.. * 1 changeset branch
+..
+.. new-state:
+..
+.. * old branch is rewritten onto another one,
+.. * the new version is then pruned.
+..
+.. expected-result:
+..
+.. * push denied
+..
+.. graph-summary:
+..
+..   A ø⇠⊗ A'
+.. | |
+.. C ◔ | ○ B
+..\|/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir D6
+  $ cd D6
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B0
+  created new head
+  $ mkcommit A1
+  $ hg up '0'
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ hg debugobsolete `getid "desc(A0)"` `getid "desc(A1)"`
+  $ hg debugobsolete --record-parents `getid "desc(A1)"`
+  $ hg log -G --hidden
+  @  0f88766e02d6 (draft): C0
+  |
+  | x  ba93660aff8d (draft): A1
+  | |
+  | o  74ff5441d343 (draft): B0
+  |/
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push --rev 'desc(C0)'
+  pushing to $TESTTMP/D6/server (glob)
+  searching for changes
+  abort: push creates new remote head 0f88766e02d6!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 09 of 17] obsolescence: add test for the "branch replacement" logic during push, case A8

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093544 -7200
#  Thu Apr 13 16:25:44 2017 +0200
# Node ID 411996b34422a3ae5de800082406502df7e9c0cb
# Parent  17791b0c8d8446ad8f59352beb2975823d7c2f3e
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 411996b34422
obsolescence: add test for the "branch replacement" logic during push, case A8

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A8.t 
b/tests/test-push-checkheads-superceed-A8.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A8.t
@@ -0,0 +1,79 @@
+
+Testing head checking code: Case A-8
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 8: single-changeset branch indirect rewrite
+
+.. old-state:
+..
+.. * 1-changeset branch
+..
+.. new-state:
+..
+.. * 1-changeset branch succeeding to A, through another unpushed changesets
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   A'
+..   A ø⇠ø⇠◔ A''
+.. |/ /
+.. | /
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A8
+  $ cd A8
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A2
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete `getid "desc(A1)" ` `getid "desc(A2)"`
+  $ hg log -G --hidden
+  @  c1f8d089020f (draft): A2
+  |
+  | x  f6082bc4ffef (draft): A1
+  |/
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A8/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files (+1 heads)
+  2 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 04 of 17] obsolescence: add test for the "branch replacement" logic during push, case A3

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093398 -7200
#  Thu Apr 13 16:23:18 2017 +0200
# Node ID 51dce1178a92660974fe210eff66d43b91986a31
# Parent  49528b84be71140af7371b7b758b8b7832fe1346
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 51dce1178a92
obsolescence: add test for the "branch replacement" logic during push, case A3

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test case.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A3.t 
b/tests/test-push-checkheads-superceed-A3.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A3.t
@@ -0,0 +1,90 @@
+
+Testing head checking code: Case A-3
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 3: multi-changeset branch with reordering
+
+Push should be allowed
+.. old-state:
+..
+.. * 2 changeset branch
+..
+.. new-state:
+..
+.. * 2 changeset branch succeeding the old one with reordering
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   B ø⇠⇠
+.. | ⇡
+..   A ø⇠⇠⇠○ A'
+.. | ⇡/
+.. | ○ B'
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A3
+  $ cd A3
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/A3/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B1
+  created new head
+  $ mkcommit A1
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete `getid "desc(B0)" ` `getid "desc(B1)"`
+  $ hg log -G --hidden
+  @  c1c7524e9488 (draft): A1
+  |
+  o  25c56d33e4c4 (draft): B1
+  |
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A3/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  2 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 12 of 17] obsolescence: add test for the "branch replacement" logic during push, case C3

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093611 -7200
#  Thu Apr 13 16:26:51 2017 +0200
# Node ID b69de92d3b93aedaf2eb2acd54711f4318e0560a
# Parent  90e43b820d4b79a7a1656acabd587d0554a9478e
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r b69de92d3b93
obsolescence: add test for the "branch replacement" logic during push, case C3

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-partial-C3.t 
b/tests/test-push-checkheads-partial-C3.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-partial-C3.t
@@ -0,0 +1,82 @@
+
+Testing head checking code: Case C-3
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category C: case were the branch is only partially obsoleted
+TestCase 3: 2 changeset branch, only the head is pruned
+
+.. old-state:
+..
+.. * 2 changeset branch
+..
+.. new-state:
+..
+.. * old head is pruned
+.. * 1 new unrelated branch
+..
+.. expected-result:
+..
+.. * push denied
+..
+.. graph-summary:
+..
+..   B ⊗
+.. |
+..   A ◔ ◔ C
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir C3
+  $ cd C3
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/C3/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ hg debugobsolete --record-parents `getid "desc(B0)"`
+  $ hg log -G --hidden
+  @  0f88766e02d6 (draft): C0
+  |
+  | x  d73caddc5533 (draft): B0
+  | |
+  | o  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/C3/server (glob)
+  searching for changes
+  abort: push creates new remote head 0f88766e02d6!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 01 of 17] obsolescence: add test utility for the "branch replacement" logic during push

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093345 -7200
#  Thu Apr 13 16:22:25 2017 +0200
# Node ID dabd8890b002c3cf3ae59526a956404b381e6d3e
# Parent  2bf73e351eb1bb086e30c9f58543817fb05e558c
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r dabd8890b002
obsolescence: add test utility for the "branch replacement" logic during push

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test case.

This changeset introduce the common setup script used by these tests.

diff --git a/tests/testlib/push-checkheads-util.sh 
b/tests/testlib/push-checkheads-util.sh
new file mode 100644
--- /dev/null
+++ b/tests/testlib/push-checkheads-util.sh
@@ -0,0 +1,44 @@
+# setup config and various utility to test new heads checks on push
+
+cat >> $HGRCPATH < "$1"
+   hg add "$1"
+   hg ci -m "$1"
+}
+
+getid() {
+   hg log --hidden --template '{node}\n' --rev "$1"
+}
+
+setuprepos() {
+echo creating basic server and client repo
+hg init server
+cd server
+mkcommit root
+hg phase --public .
+mkcommit A0
+cd ..
+hg clone server client
+}
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 13 of 17] obsolescence: add test for the "branch replacement" logic during push, case C4

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093625 -7200
#  Thu Apr 13 16:27:05 2017 +0200
# Node ID 6736a9b9c663e92870afaa850ccc32b497f8a3b9
# Parent  b69de92d3b93aedaf2eb2acd54711f4318e0560a
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 6736a9b9c663
obsolescence: add test for the "branch replacement" logic during push, case C4

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-partial-C4.t 
b/tests/test-push-checkheads-partial-C4.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-partial-C4.t
@@ -0,0 +1,82 @@
+
+Testing head checking code: Case C-4
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category C: case were the branch is only partially obsoleted
+TestCase 4: 2 changeset branch, only the base is pruned
+
+.. old-state:
+..
+.. * 2 changeset branch
+..
+.. new-state:
+..
+.. * old base is pruned
+.. * 1 new unrelated branch
+..
+.. expected-result:
+..
+.. * push denied
+..
+.. graph-summary:
+..
+..   B ◔
+.. |
+..   A ⊗ ◔ C
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir C4
+  $ cd C4
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/C4/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ hg debugobsolete --record-parents `getid "desc(A0)"`
+  $ hg log -G --hidden
+  @  0f88766e02d6 (draft): C0
+  |
+  | o  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push --rev 'desc(C0)'
+  pushing to $TESTTMP/C4/server (glob)
+  searching for changes
+  abort: push creates new remote head 0f88766e02d6!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 07 of 17] obsolescence: add test for the "branch replacement" logic during push, case A6

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093511 -7200
#  Thu Apr 13 16:25:11 2017 +0200
# Node ID 8945cea7790124a5d1b297770464f7ddf42d08f2
# Parent  aa51e7b4eb2be8f728c5c12fae72d4e7163d17f1
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 8945cea77901
obsolescence: add test for the "branch replacement" logic during push, case A6

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A6.t 
b/tests/test-push-checkheads-superceed-A6.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A6.t
@@ -0,0 +1,98 @@
+
+Testing head checking code: Case A-6
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 6: multi-changeset branch, split on multiple other, (base on its own 
branch), same number of head
+
+.. old-state:
+..
+.. * 2 branch (1-changeset, and 2-changesets)
+..
+.. new-state:
+..
+.. * 1 new branch superceeding the base of the old-2-changesets-branch,
+.. * 1 new changesets on the old-1-changeset-branch superceeding the head of 
the other
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+.. B'◔⇢ø B
+..   | |
+.. A | ø⇠◔ A'
+..   | |/
+.. C ● |
+..\|
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A6
+  $ cd A6
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ hg up 0
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  $ mkcommit C0
+  created new head
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/A6/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  (run 'hg heads' to see heads, 'hg merge' to merge)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg up 'desc(C0)'
+  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B1
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete `getid "desc(B0)" ` `getid "desc(B1)"`
+  $ hg log -G --hidden
+  @  d70a1f75a020 (draft): B1
+  |
+  | o  f6082bc4ffef (draft): A1
+  | |
+  o |  0f88766e02d6 (draft): C0
+  |/
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A6/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  2 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 14 of 17] obsolescence: add test for the "branch replacement" logic during push, case D1

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093648 -7200
#  Thu Apr 13 16:27:28 2017 +0200
# Node ID 77f468948bb7c9eea215d7447fd379042d760f37
# Parent  6736a9b9c663e92870afaa850ccc32b497f8a3b9
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 77f468948bb7
obsolescence: add test for the "branch replacement" logic during push, case D1

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-unpushed-D1.t 
b/tests/test-push-checkheads-unpushed-D1.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-unpushed-D1.t
@@ -0,0 +1,77 @@
+
+Testing head checking code: Case D-1
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category D: remote head is "obs-affected" locally, but result is not part of 
the push
+TestCase 1: remote head is rewritten, but successors is not part of the push
+
+.. old-state:
+..
+.. * 1 changeset branch
+..
+.. new-state:
+..
+.. * 1 changeset branch succeeding the old branch
+.. * 1 new unrelated branch
+..
+.. expected-result:
+..
+.. * pushing only the unrelated branch: denied
+..
+.. graph-summary:
+..
+..   A ø⇠○ A'
+.. |/
+.. | ◔ B
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir D1
+  $ cd D1
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit B0
+  created new head
+  $ hg log -G --hidden
+  @  74ff5441d343 (draft): B0
+  |
+  | o  f6082bc4ffef (draft): A1
+  |/
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push -r 'desc(B0)'
+  pushing to $TESTTMP/D1/server (glob)
+  searching for changes
+  abort: push creates new remote head 74ff5441d343!
+  (merge or see 'hg help push' for details about pushing new heads)
+  [255]
+
+  $ cd ../..
+
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 05 of 17] obsolescence: add test for the "branch replacement" logic during push, case A4

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093419 -7200
#  Thu Apr 13 16:23:39 2017 +0200
# Node ID 28f833e962f797924e599da54c06ecf01a37a802
# Parent  51dce1178a92660974fe210eff66d43b91986a31
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 28f833e962f7
obsolescence: add test for the "branch replacement" logic during push, case A4

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test cases.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A4.t 
b/tests/test-push-checkheads-superceed-A4.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A4.t
@@ -0,0 +1,74 @@
+
+Testing head checking code: Case A-4
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 4: New changeset as children of the successor
+
+.. old-state:
+..
+.. * 1-changeset branch
+..
+.. new-state:
+..
+.. * 2-changeset branch, first is a successor, but head is new
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   ◔ B
+..   |
+..   A ø⇠◔ A'
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A4
+  $ cd A4
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd client
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ mkcommit B0
+  $ hg log -G --hidden
+  @  f40ded968333 (draft): B0
+  |
+  o  f6082bc4ffef (draft): A1
+  |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A4/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  1 new obsolescence markers
+
+  $ cd ../../
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 03 of 17] obsolescence: add test for the "branch replacement" logic during push, case A2

[Pierre-Yves David]

# HG changeset patch
# User Pierre-Yves David 
# Date 1492093381 -7200
#  Thu Apr 13 16:23:01 2017 +0200
# Node ID 49528b84be71140af7371b7b758b8b7832fe1346
# Parent  333e1a68d81e20aaed1569cf1749b0028b294efb
# EXP-Topic push.checkheads
# Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
#  hg pull 
https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 49528b84be71
obsolescence: add test for the "branch replacement" logic during push, case A2

Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.

The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test case.

See inline documentation for details about the test case added in this
changeset.

diff --git a/tests/test-push-checkheads-superceed-A2.t 
b/tests/test-push-checkheads-superceed-A2.t
new file mode 100644
--- /dev/null
+++ b/tests/test-push-checkheads-superceed-A2.t
@@ -0,0 +1,87 @@
+
+Testing head checking code: Case A-2
+
+
+Mercurial checks for the introduction of new heads on push. Evolution comes
+into play to detect if existing branches on the server are being replaced by
+some of the new one we push.
+
+This case is part of a series of tests checking this behavior.
+
+Category A: simple case involving a branch being superceeded by another.
+TestCase 2: multi-changeset branch
+
+.. old-state:
+..
+.. * 1 branch with 2 changesets
+..
+.. new-state:
+..
+.. * another 2-changeset branch succeeding the old one
+..
+.. expected-result:
+..
+.. * push allowed
+..
+.. graph-summary:
+..
+..   B ø⇠◔ B'
+.. | |
+..   A ø⇠◔ A'
+.. |/
+.. ●
+
+  $ . $TESTDIR/testlib/push-checkheads-util.sh
+
+Test setup
+--
+
+  $ mkdir A2
+  $ cd A2
+  $ setuprepos
+  creating basic server and client repo
+  updating to branch default
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cd server
+  $ mkcommit B0
+  $ cd ../client
+  $ hg pull
+  pulling from $TESTTMP/A2/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 1 changesets with 1 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg up 0
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ mkcommit A1
+  created new head
+  $ mkcommit B1
+  $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"`
+  $ hg debugobsolete `getid "desc(B0)" ` `getid "desc(B1)"`
+  $ hg log -G --hidden
+  @  262c8c798096 (draft): B1
+  |
+  o  f6082bc4ffef (draft): A1
+  |
+  | x  d73caddc5533 (draft): B0
+  | |
+  | x  8aaa48160adc (draft): A0
+  |/
+  o  1e4be0697311 (public): root
+  
+
+Actual testing
+--
+
+  $ hg push
+  pushing to $TESTTMP/A2/server (glob)
+  searching for changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 2 changesets with 2 changes to 2 files (+1 heads)
+  2 new obsolescence markers
+
+  $ cd ../..
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] gitweb: plug followlines UI in filerevision view

[Augie Fackler]

On Thu, Apr 13, 2017 at 11:05:21AM +0200, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde 
> # Date 1492069788 -7200
> #  Thu Apr 13 09:49:48 2017 +0200
> # Node ID 47f250d6b023897eb99f9892f9b379b3187b1c84
> # Parent  c2e6e944113633a3051c78e773d2b09656a80718
> # Available At http://hg.logilab.org/users/dlaxalde/hg
> #  hg pull http://hg.logilab.org/users/dlaxalde/hg -r 47f250d6b023
> # EXP-Topic followlines/gitweb
> gitweb: plug followlines UI in filerevision view

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

Re: [PATCH] util: fix human-readable printing of negative byte counts

[Yuya Nishihara]

On Tue, 11 Apr 2017 18:41:52 +0200, Gábor Stefanik wrote:
> # HG changeset patch
> # User Gábor Stefanik 
> # Date 1491840990 -7200
> #  Mon Apr 10 18:16:30 2017 +0200
> # Node ID c3d89ef348120ead9c2280c55d05c7ce435ea589
> # Parent  e0dc40530c5aa514feb6a09cf79ab6a3aa2ec331
> util: fix human-readable printing of negative byte counts
> 
> Apply the same human-readable printing rules to negative byte counts as to
> positive ones. Fixes output of debugupgraderepo.

Looks good, queued, thanks.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 4 shelve-ext v3] shelve: make shelvestate use simplekeyvaluefile

[Yuya Nishihara]

On Wed, 12 Apr 2017 21:34:23 +, Kostia Balytskyi wrote:
> > -Original Message-
> > From: Yuya Nishihara [mailto:you...@gmail.com] On Behalf Of Yuya
> > Nishihara
> > Sent: Wednesday, 12 April, 2017 16:03
> > To: Kostia Balytskyi 
> > Cc: mercurial-devel@mercurial-scm.org
> > Subject: Re: [PATCH 4 of 4 shelve-ext v3] shelve: make shelvestate use
> > simplekeyvaluefile
> > 
> > On Mon, 10 Apr 2017 16:28:36 -0700, Kostia Balytskyi wrote:
> > > # HG changeset patch
> > > # User Kostia Balytskyi  # Date 1491866434 25200
> > > #  Mon Apr 10 16:20:34 2017 -0700
> > > # Node ID 8e286a85816581cfa4ce44768482cb5722a88bb3
> > > # Parent  961539160565df5052d1c770788cacb2d76e9752
> > > shelve: make shelvestate use simplekeyvaluefile
> > >
> > > Currently shelvestate uses line ordering to differentiate fields. This
> > > makes it hard for extensions to wrap shelve, since if two alternative
> > > versions of code add a new line, correct merging is going to be 
> > > problematic.
> > > simplekeyvaluefile was introduced fot this purpose specifically.
> > >
> > > After this patch:
> > > - shelve will always write a simplekeyvaluefile, unless 
> > > 'shelve.oldstatefile'
> > > is on
> > > - unshelve will check the first line of the file and if it has '='
> > > sign, will treat the file as a simplekeyvalue one. Otherwise, it will
> > > try to read an old-style statefile.
> > >
> > > Test change is needed, because just a few lines below the place of
> > > change, test script does a direct manipulation of shelvestate file by
> > > removing a line in a particular position. Clearly, this relies on the
> > > fact that the file is  is position-based, not key-value.
> > >
> > > diff --git a/hgext/shelve.py b/hgext/shelve.py
> > > --- a/hgext/shelve.py
> > > +++ b/hgext/shelve.py
> > > @@ -166,6 +166,10 @@ class shelvedstate(object):
> > >
> > >  Handles saving and restoring a shelved state. Ensures that different
> > >  versions of a shelved state are possible and handles them 
> > > appropriately.
> > > +
> > > +By default, simplekeyvaluefile is used. The following config option
> > > +allows one to enforce the old position-based state file to be used:
> > > +shelve.oldstatefile
> > >  """
> > >  _version = 1
> > 
> > I think this is the version 2 of the state file.
> > 
> > And I don't think the config knob is good way to support old state file. If 
> > we
> > want to support writing old state files, we can write two separate files, 
> > like
> > mergestate. If not, we only need to switch parsers depending on the version
> > field, like histedit.
> 
> The idea behind this was that old state files should almost never be written. 
> And I can't really think of any reason we would want to write them, except 
> for that one test, which can be adjusted.

Then, how about adding undocumented 'debug.' config for testing
purpose?

> > > @@ -175,6 +179,18 @@ class shelvedstate(object):
> > >  _noactivebook = ':no-active-bookmark'
> > >
> > >  @classmethod
> > > +def iskeyvaluebased(cls, repo):
> > > +"""Determine whether state file is simple lines or
> > simplekeyvaluefile"""
> > > +if repo.ui.configbool('shelve', 'oldstatefile', False):
> > > +return True
> > > +fp = repo.vfs(cls._filename)
> > > +try:
> > > +firstline = fp.readline()
> > > +return '=' in firstline
> > > +finally:
> > > +fp.close()
> > 
> > Perhaps it's better to compare the version number instead of relying on
> > heuristic.
> Comparing versions (if I understand you correctly) wouldn't work, see below.

I couldn't get why new format can't be version 2. The old format had '1\n'
for future extension. This patch introduces new format, so using '2\n' makes
sense to me.

The current simplekeyvaluefile API would make this a bit harder, but we can
extract functions to serialize and deserialize dict from/to file object.

> > > +@classmethod
> > >  def load(cls, repo):
> > >  # Order is important, because old shelvestate file uses it
> > >  # to detemine values of fields (i.g. version is on the first
> > > line, @@ -182,12 +198,15 @@ class shelvedstate(object):
> > >  keys = ['version', 'name', 'originalwctx', 'pendingctx', 
> > > 'parents',
> > >  'nodestoremove', 'branchtorestore', 'keep', 'activebook']
> > >  d = {}
> > > -fp = repo.vfs(cls._filename)
> > > -try:
> > > -for key in keys:
> > > -d[key] = fp.readline().strip()
> > > -finally:
> > > -fp.close()
> > > +if cls.iskeyvaluebased(repo):
> > > +d = scmutil.simplekeyvaluefile(repo.vfs, 
> > > cls._filename).read()
> > > +else:
> > > +fp = repo.vfs(cls._filename)
> > > +try:
> > > +for key in keys:
> > > +d[key] = fp.readline().strip()
> > > + 

Re: [PATCH v2] show: make template option actually show up in help

[Yuya Nishihara]

On Thu, 13 Apr 2017 03:45:43 -0700, Ryan McElroy wrote:
> # HG changeset patch
> # User Ryan McElroy 
> # Date 1492078673 25200
> #  Thu Apr 13 03:17:53 2017 -0700
> # Node ID 7b40e2f960e9b53ce3e9f0ae3a6fe22b4f921297
> # Parent  3c77f03f16b386940c60af36d6a3ad83bee37ad4
> show: make template option actually show up in help

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

Re: [PATCH 2 of 2 V2] show: implement underway view

[Yuya Nishihara]

On Wed, 12 Apr 2017 20:31:36 -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1492054275 25200
> #  Wed Apr 12 20:31:15 2017 -0700
> # Node ID b223da52ad3b22bb76dcb240677d330bce3eb6bf
> # Parent  60177a9b778cb65fdefd4486ce51475a746c4cb6
> show: implement underway view

> +# Add working directory parent.
> +wdirrev = repo['.'].rev()
> +if wdirrev != nullrev:
> +relevant += revset.baseset(set([wdirrev]))

Nit: "wdir" means repo[None].
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2 V2] show: fix formatting of multiple commands

[Yuya Nishihara]

On Wed, 12 Apr 2017 20:31:35 -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1492054124 25200
> #  Wed Apr 12 20:28:44 2017 -0700
> # Node ID 60177a9b778cb65fdefd4486ce51475a746c4cb6
> # Parent  6ce09d2cc2db6aeed0b46da1b26426798d91833c
> show: fix formatting of multiple commands

Queued these, thanks.

> +def _updatedocstring():
> +longest = max(map(len, showview._table.keys()))
> +entries = []
> +for key in sorted(showview._table.keys()):
> +entries.append(pycompat.sysstr('%s   %s' % (
> +key.ljust(longest), showview._table[key]._origdoc)))

Perhaps you want a field definition list: ':%s: %s'.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] pycompat: import correct cookie module on Python 3

[Yuya Nishihara]

On Wed, 12 Apr 2017 18:42:27 -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1492047740 25200
> #  Wed Apr 12 18:42:20 2017 -0700
> # Node ID c5941562f2a6ead0503f609386c53b6a919a7175
> # Parent  6ce09d2cc2db6aeed0b46da1b26426798d91833c
> pycompat: import correct cookie module on Python 3

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

Re: [PATCH 1 of 2 V2] util: add a way to issue deprecation warning without a UI object

[Yuya Nishihara]

On Thu, 13 Apr 2017 01:14:48 +0200, Pierre-Yves David wrote:
> 
> 
> On 04/10/2017 04:35 PM, Yuya Nishihara wrote:
> > On Mon, 10 Apr 2017 15:41:08 +0200, Pierre-Yves David wrote:
> >> On 04/09/2017 03:08 PM, Yuya Nishihara wrote:
> >>> On Sat, 8 Apr 2017 11:37:20 +0200, Pierre-Yves David wrote:
>  On 04/08/2017 10:16 AM, Yuya Nishihara wrote:
> > On Fri, 7 Apr 2017 19:03:55 +0200, Pierre-Yves David wrote:
> >> On 04/06/2017 05:44 PM, Yuya Nishihara wrote:
> >>> On Thu, 6 Apr 2017 16:09:07 +0200, Pierre-Yves David wrote:
> > If dirty hack allowed, I would do something like the following:
> >
> >   # util.py
> >   def _deprecwarn(msg, version):
> >   pass
> >
> >   # somewhere ui is available, maybe in dispatch.py
> >   util._deprecwarn = ui.deprecwarn
> 
>  That is a diry hack. I would prefer we did not used it.
> >>>
> >>> Yeah, that is dirty and I don't like it. But I'm okay with it as long 
> >>> as
> >>> it is a temporary hack.
> >>
> >> If you think the dirty hack is worth the potential extra exposure, I'm
> >> fine with it.
> >>
> >> However, I'm confused about your usage of "temporary hack" here. Why 
> >> are
> >> you using temporary?
> >
> > I suppose the hack will hopefully disappear with the vfs compat layer. 
> > I'm not
> > sure if a permanent one is necessary.
> 
>  I think this kind of needs will appears again in the future. So I would
>  not flag the solution as temporary. I would have made the function local
>  to the scmutil module.
> 
>  So I would rather have a long terms solution. What do you think?
> >>>
> >>> If we need less ad-hoc one, I would add a global flag to enable deprecwarn
> >>> and set it only by global configuration (i.e. ui, not lui nor repo.ui.)
> >>
> >> This seems a bit hacky (I also have some concerns about possible of
> >> deprecated function being created before the ui is. but I'm not sure
> >> they are funded).
> >
> > IMHO it's as bad as using environment variable. Both are a kind of globals.
> 
> The global assignment possibly keeps an object alive longer than its due 
> time. So I find it a bit hackier.

That's why I proposed a global boolean flag as an alternative.

> >>> And perhaps will remove ui.deprecwarn() in favor of util.deprecwarn().
> >>
> >> ui.deprecwarn is much more configurable and manageable that the global
> >> one (based on Python deprec warning). I do not think we should drop
> >> `ui.deprecwarc` in favor of the other one.
> >
> > It's more configurable, but less easy to use because ui is required.
> >
> > Anyway, I don't think it's worth spending time for designing the deprecwarn
> > feature. I'm okay for any of the ideas in this thread.
> 
> This the current series is right here and implemented. Are you okay with 
> moving forward with it?

Sure. Can you rebase these on tip? The first patch couldn't apply.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2] pager: set some environment variables if they're not set

[Yuya Nishihara]

On Wed, 12 Apr 2017 16:51:05 -0700, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu 
> # Date 1492039375 25200
> #  Wed Apr 12 16:22:55 2017 -0700
> # Node ID c8f21c8e1a9a8b5ca97bb87916ede5770d6f7021
> # Parent  1c398f7f4aa437a7c692025f0434c0564dbf72ff
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> c8f21c8e1a9a
> pager: set some environment variables if they're not set
> 
> Git did this already [1] [2]. We want this behavior too [3].
> 
> This provides a better default user experience (like, supporting colors) if
> users have things like "PAGER=less" set, which is not uncommon.
> 
> [1]: 
> https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/pager.c#L87
> [2]: 
> https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/Makefile#L1545
> [3]: 
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094780.html

> diff --git a/mercurial/help/pager.txt b/mercurial/help/pager.txt
> --- a/mercurial/help/pager.txt
> +++ b/mercurial/help/pager.txt
> @@ -34,2 +34,11 @@ To globally turn off all attempts to use
>  
>  which will prevent the pager from running.
> +
> +In order to provide a better default user experience, some environment
> +variables will be set if they are not set. For example, if LESS is not set, 
> it
> +will be set to FRX. To override the list of environment variables, set::
> +
> +  [pager]
> +  defaultenv = LESS=FRQXi, LESSKEY=~/.lesskey
> +
> +Commas are needed to separate multiple default environment variables.
> diff --git a/mercurial/ui.py b/mercurial/ui.py
> --- a/mercurial/ui.py
> +++ b/mercurial/ui.py
> @@ -855,4 +855,13 @@ class ui(object):
>  return
>  
> +pagerenv = encoding.environ.copy()
> +for entry in self.configlist('pager', 'defaultenv',
> + ['LESS=FRX', 'LV=-c']):
> +if '=' not in entry:
> +raise error.Abort(_('invalid pager.defaultenv config: %s')
> +  % entry)
> +name, value = entry.split('=', 1)
> +pagerenv.setdefault(name, value)

Instead of introducing defaultenv config, how about always setting
"LESS=FRX LV=-c" unless they are in environ dict? Users can easily override
them by pager command:

  [pager]
  pager = LESS=whatever less

I feel writing environs in the configlist syntax isn't nice.

> @@ -913,5 +922,6 @@ class ui(object):
>  command, shell=shell, bufsize=-1,
>  close_fds=util.closefds, stdin=subprocess.PIPE,
> -stdout=util.stdout, stderr=util.stderr)
> +stdout=util.stdout, stderr=util.stderr,
> +env=util.shellenviron(env))

Nit: util.shellenviron() only needs a partial environ dict to override.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] chg: respect environment variables for pager

[Yuya Nishihara]

On Wed, 12 Apr 2017 16:51:06 -0700, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu 
> # Date 1492041023 25200
> #  Wed Apr 12 16:50:23 2017 -0700
> # Node ID 5972f38edf036bab36f41cb0835d21c3cf1ab5e5
> # Parent  c8f21c8e1a9a8b5ca97bb87916ede5770d6f7021
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> 5972f38edf03
> chg: respect environment variables for pager

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

[PATCH v2] show: make template option actually show up in help

[Ryan McElroy]

# HG changeset patch
# User Ryan McElroy 
# Date 1492078673 25200
#  Thu Apr 13 03:17:53 2017 -0700
# Node ID 7b40e2f960e9b53ce3e9f0ae3a6fe22b4f921297
# Parent  3c77f03f16b386940c60af36d6a3ad83bee37ad4
show: make template option actually show up in help

Previously, the --template/-T option didn't show up in help because it's marked
as experimental. It's not really experimental for show, and its quite important
for show's funcationality, so let's make sure it always shows up.

diff --git a/hgext/show.py b/hgext/show.py
--- a/hgext/show.py
+++ b/hgext/show.py
@@ -17,7 +17,6 @@ from __future__ import absolute_import
 from mercurial.i18n import _
 from mercurial import (
 cmdutil,
-commands,
 error,
 formatter,
 pycompat,
@@ -53,7 +52,14 @@ class showcmdfunc(registrar._funcregistr
 
 showview = showcmdfunc()
 
-@command('show', commands.formatteropts, _('VIEW'))
+@command('show', [
+# TODO: Switch this template flag to use commands.formatteropts if
+# 'hg show' becomes stable before --template/-T is stable. For now,
+# we are putting it here without the '(EXPERIMENTAL)' flag because it
+# is an important part of the 'hg show' user experience and the entire
+# 'hg show' experience is experimental.
+('T', 'template', '', ('display with template'), _('TEMPLATE')),
+], _('VIEW'))
 def show(ui, repo, view=None, template=None):
 """show various repository information
 
diff --git a/tests/test-show.t b/tests/test-show.t
--- a/tests/test-show.t
+++ b/tests/test-show.t
@@ -43,6 +43,8 @@ No arguments shows available views
   
   options:
   
+   -T --template TEMPLATE display with template
+  
   (some details hidden, use --verbose to show complete help)
 
 Unknown view prints error
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 5] show: standarize abort output with help output

[Ryan McElroy]

On 4/12/17 4:29 PM, Yuya Nishihara wrote:

On Wed, 12 Apr 2017 12:35:22 +0100, Ryan McElroy wrote:

On 4/11/17 2:01 PM, Yuya Nishihara wrote:

On Mon, 10 Apr 2017 02:41:05 -0700, Ryan McElroy wrote:



show: standarize abort output with help output



 Available views:
 
-   bookmarks   bookmarks and their associated changeset

+  bookmarks -- bookmarks and their associated changeset

Perhaps the original version derives from "hg help", which seems more
standard.

So to be clear we're okay with the divergent output here? It bothers me
since both are sharing the same "source of truth" (the docblocks), but I
can get over it.

I prefer not having the divergent output, but the original output with no
dash seems more common.

Perhaps we wouldn't want to modify docstring by registrar. The comment says
"consider using formatter" so we'll need (name, doc) pair not "name doc"
string, something like this:


It looks like Greg just sent out some patches cleaning up the output a 
bit. I'll wait to see discussion on those before I proceed in any 
particular direction here.




@@ -36,8 +36,8 @@ command = cmdutil.command(cmdtable)
  class showcmdfunc(registrar._funcregistrarbase):
  """Register a function to be invoked for an `hg show `."""
  
-# Used by _formatdoc().

-_docformat = '%s -- %s'
+def _formatdoc(self, decl, doc):
+return doc
  
  def _extrasetup(self, name, func, fmtopic=None):

  """Called with decorator arguments to register a show view.
@@ -87,7 +87,8 @@ def show(ui, repo, view=None, template=N
  ui.write('\n')
  
  for name, func in sorted(views.items()):

-ui.write(('%s\n') % func.__doc__)
+# this will be fm.write() ?
+ui.write((' %s   %s\n') % (name, func.__doc__))
  
  ui.write('\n')

  raise error.Abort(_('no view requested'),


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

Re: [PATCH 4 of 5] show: make template option actually show up in help

[Ryan McElroy]

On 4/12/17 4:37 PM, Yuya Nishihara wrote:

On Wed, 12 Apr 2017 12:34:14 +0100, Ryan McElroy wrote:

On 4/11/17 2:00 PM, Yuya Nishihara wrote:

On Mon, 10 Apr 2017 02:41:06 -0700, Ryan McElroy wrote:

# HG changeset patch
# User Ryan McElroy 
# Date 1491817029 25200
#  Mon Apr 10 02:37:09 2017 -0700
# Node ID eefe70d59a3ea5a09b5711ea8d7c568002a8d9e3
# Parent  ee1bd54bfda1dd1aea0f9b2397ddeae42d58c54a
show: make template option actually show up in help

Previously, the --template/-T option didn't show up in help because it's marked
as experimental. It's not really experimental for show, and its quite important
for show's funcationality, so let's make sure it always shows up.

I prefer not making show() diverged from the other commands taking -T option.
"hg show" is experimental anyway.

Right now, the output looks silly and confusing. It ends with:

(use 'hg help -e show' to show help for the show extension)

options:

(some details hidden, use --verbose to show complete help)

Yes, that's an empty list of options, which looks really weird.

I'm okay with that because the command is experimental, but yeah it's weird.

Can you resend this with some TODO comment so we'll never expose the -T
option when "show" gets stable but -T is still experimental?


Sure, will send follow-ups. Thanks for the review!

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

[PATCH 1 of 3] gitweb: add information about "linerange" filtering in filelog view

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1492070398 -7200
#  Thu Apr 13 09:59:58 2017 +0200
# Node ID 9696387c1d02ac29d3c9384ec37419aed2924f53
# Parent  6ce09d2cc2db6aeed0b46da1b26426798d91833c
# Available At http://hg.logilab.org/users/dlaxalde/hg
#  hg pull http://hg.logilab.org/users/dlaxalde/hg -r 9696387c1d02
# EXP-Topic followlines/gitweb
gitweb: add information about "linerange" filtering in filelog view

As for paper style, in 5e6d44511317, we display a "(following lines
: back to filelog)" message alongside the
file name when "linerange" query parameter is present.

diff --git a/mercurial/templates/gitweb/filelog.tmpl 
b/mercurial/templates/gitweb/filelog.tmpl
--- a/mercurial/templates/gitweb/filelog.tmpl
+++ b/mercurial/templates/gitweb/filelog.tmpl
@@ -31,7 +31,10 @@ revisions |
 {nav%filenav}
 
 
-{file|urlescape}
+
+  {file|urlescape}{if(linerange,
+' (following lines {linerange}{if(descend, ', descending')} back
 to filelog)')}
+
 
 
 {entries%filelogentry}
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 3] gitweb: handle "patch" query parameter in filelog view

[Denis Laxalde]

# HG changeset patch
# User Denis Laxalde 
# Date 1492070649 -7200
#  Thu Apr 13 10:04:09 2017 +0200
# Node ID c2e6e944113633a3051c78e773d2b09656a80718
# Parent  9696387c1d02ac29d3c9384ec37419aed2924f53
# Available At http://hg.logilab.org/users/dlaxalde/hg
#  hg pull http://hg.logilab.org/users/dlaxalde/hg -r c2e6e9441136
# EXP-Topic followlines/gitweb
gitweb: handle "patch" query parameter in filelog view

As for paper style, in f36dc643ffdc, we display "diff" data as an additional
row in the table of revision entries for the gitweb template.
Also, as these additional diff rows have a white background, they may be
confused with log entry rows ("age", "author", "description", "links") of even
parity (parity0 also have a white background). So we disable parity colors for
log entry rows when diff is displayed and fix the color to the
"dark" parity (i.e. parity1 #f6f6f0) so that it's always distinguishable from
diff rows.

diff --git a/mercurial/templates/gitweb/map b/mercurial/templates/gitweb/map
--- a/mercurial/templates/gitweb/map
+++ b/mercurial/templates/gitweb/map
@@ -282,7 +282,7 @@ shortlogentry = '
 
   '
 filelogentry = '
-  
+  
 {date|rfc822date}
 {author|person}
 
@@ -297,7 +297,8 @@ filelogentry = '
   annotate
   {rename%filelogrename}
 
-  '
+  
+  {if(patch, '{diff}')}'
 archiveentry = ' | {type|escape}
 '
 indexentry = '
   
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel