[Bug 5540] New: Stripping a working directory parent may switch named branches

[mercurial-bugs]

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

Bug ID: 5540
   Summary: Stripping a working directory parent may switch named
branches
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: strip
  Assignee: bugzi...@mercurial-scm.org
  Reporter: matt_harbi...@yahoo.com
CC: mercurial-devel@mercurial-scm.org

It's a bit surprising, given how hard `hg update` tries to stay on the current
named branch without an explicit destination.  There's no indication of the
switch in the command output (though there is an "X files
updated/merged/removed" message).  It requires a merge as part of the strip
range to trigger.  Here's an example based on the tests for 4.2-rc:

diff --git a/tests/test-strip.t b/tests/test-strip.t
--- a/tests/test-strip.t
+++ b/tests/test-strip.t
@@ -935,4 +935,97 @@
   abort: boom
   [255]

+  $ hg log -G
+  @  changeset:   1:eca11cf91c71
+  |  tag: tip
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: commitB
+  |
+  o  changeset:   0:105141ef12d0
+ user:test
+ date:Thu Jan 01 00:00:00 1970 +
+ summary: commitA
+
+  $ hg branch new-branch
+  marked working directory as branch new-branch
+  (branches are permanent and global, did you want a bookmark?)
+  $ hg ci -m "start new branch"
+  $ echo 'foo' > foo.txt
+  $ hg ci -Aqm foo
+  $ hg up default
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ echo 'bar' > bar.txt
+  $ hg ci -Aqm bar
+  $ hg up new-branch
+  1 files updated, 0 files merged, 1 files removed, 0 files unresolved
+  $ hg merge default
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  (branch merge, don't forget to commit)
+  $ hg ci -m merge
+  $ hg log -G
+  @changeset:   5:4cf5e92caec2
+  |/   branch:  new-branch (glob)
+  | |  tag: tip
+  | |  parent:  3:f62c6c09b707
+  | |  parent:  4:35358f982181
+  | |  user:test
+  | |  date:Thu Jan 01 00:00:00 1970 +
+  | |  summary: merge
+  | |
+  | o  changeset:   4:35358f982181
+  | |  parent:  1:eca11cf91c71
+  | |  user:test
+  | |  date:Thu Jan 01 00:00:00 1970 +
+  | |  summary: bar
+  | |
+  o |  changeset:   3:f62c6c09b707
+  | |  branch:  new-branch
+  | |  user:test
+  | |  date:Thu Jan 01 00:00:00 1970 +
+  | |  summary: foo
+  | |
+  o |  changeset:   2:b1d33a8cadd9
+  |/   branch:  new-branch
+  |user:test
+  |date:Thu Jan 01 00:00:00 1970 +
+  |summary: start new branch
+  |
+  o  changeset:   1:eca11cf91c71
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: commitB
+  |
+  o  changeset:   0:105141ef12d0
+ user:test
+ date:Thu Jan 01 00:00:00 1970 +
+ summary: commitA
+
+  $ hg strip -r 35358f982181
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  saved backup bundle to
$TESTTMP\issue4736\.hg\strip-backup/35358f982181-a6f020aa-backup.hg (glob)
+  $ hg log -G
+  o  changeset:   3:f62c6c09b707
+  |  branch:  new-branch
+  |  tag: tip
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: foo
+  |
+  o  changeset:   2:b1d33a8cadd9
+  |  branch:  new-branch
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: start new branch
+  |
+  @  changeset:   1:eca11cf91c71
+  |  user:test
+  |  date:Thu Jan 01 00:00:00 1970 +
+  |  summary: commitB
+  |
+  o  changeset:   0:105141ef12d0
+ user:test
+ date:Thu Jan 01 00:00:00 1970 +
+ summary: commitA
+


It is documented in the help, but it's not hard to read it such that --rev '.'
is part of the strip (especially if a range revset is given to the command),
and *its* most recent ancestor used.  If '.' was stripped explicitly in this
example instead, it does stay on the same branch.  (But isn't 35358f982181 "the
most recent available ancestor", per the help text?  The current behavior in
this case seems better in that it is more deterministic, in addition to staying
on the same branch.)

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

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

[Danek Duvall]

Gregory Szorc wrote:

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

I'm seeing

  abort: error: ''

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

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

Any thoughts on this before I spend more time digging?

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

[PATCH remotenames] remotenames: fix parameter ordering

[Wez Furlong]

# HG changeset patch
# User Wez Furlong 
# Date 1492546015 25200
#  Tue Apr 18 13:06:55 2017 -0700
# Node ID 87fa8cb8721726dcbe2c6a313b70ac770e0fc5ae
# Parent  b55f98398522d9c7cf81ab191ddd322926699b0a
remotenames: fix parameter ordering

Summary: templater function signature changed upstream

Test Plan: rt

Reviewers: #mercurial, quark

Reviewed By: quark

Differential Revision: https://phabricator.intern.facebook.com/D4908240

Signature: t1:4908240:1492545063:0d726e99e065bf231a2fcf894a1722e02e038650

diff --git a/remotenames.py b/remotenames.py
--- a/remotenames.py
+++ b/remotenames.py
@@ -1723,8 +1723,8 @@
 if (not remotenames or not suppress) and 'remotebranches' in repo.names:
 remotenames += repo.names['remotebranches'].names(repo, ctx.node())
 
-return templatekw.showlist('remotename', remotenames,
-   plural='remotenames', **args)
+return templatekw.showlist('remotename', remotenames, args,
+   plural='remotenames')
 
 #
 # bookmarks api compatibility
___
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]

I respond below, but I believe Jun has sent you a innovative proposal 
that may solve both of our needs and render this discussion irrelevant. 
So take a look at his proposal at your earliest convenience, since it 
may let us put this behind us.


On 4/18/17 11:03 AM, Pierre-Yves David wrote:

On 04/14/2017 01:04 AM, Durham Goode wrote:

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

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

[…]

*Practical example* (/simplified/):

   Situation:

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

   Way forward:

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

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


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

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


(note: I've purposely delay more "discussion" oriented part in my other
email (that you also replied to) I'll reply to it too shortly after this
one.)


In my example above, once "hg undo" is upstreamed, we are able to build
a variant without hash preservation[1] and ship that the user by default
without delay.


I'm sure you don't mean it this way, but this sounds a lot like "let's 
ship my thing and we'll figure your thing out later". The moment evolve 
ships, it becomes a lot harder to make the types of changes I'm talking 
about (both from a user experience point of view and community 
momentum), so I'd rather have the discussion now while it's still 
possible to make important changes.  If we flipped the sentence around 
(ship mine, figure yours out later) I'm sure you wouldn't be happy with 
that outcome either.



On a general principle, decoupling implementation discussion from UI
polishing is usually a win.


If we decoupled UI from implementation here, we'd just go ahead and ship 
"hg unhide" with hash preservation, since that's objectively the more 
intuitive UI for unhide. But since the implementation of the obsolete 
graph doesn't allow that UI, implementation therefore affects our 
discussion.


I'd love to discuss the pro's and con's of these two ideas purely from a 
UX standpoint, but I haven't seen any concrete examples of situations 
where evolve is affected by this for us to have a tangible discussion 
around it. If we had a concrete example, we could more productively 
evaluate the pro's and con's of these ideas.


Given that evolve has been around for years and people still aren't able 
to reason about concrete examples in these discussions, I don't think 
the strategy of 'give it more time' is going to help move this 
discussion forward.

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

[PATCH 2 of 2] show: add basic labels to work template

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1492539008 25200
#  Tue Apr 18 11:10:08 2017 -0700
# Node ID 7f5f78179f5f6afc0f4bea52aa03f1431e03d3d9
# Parent  d8d4b4acc68859f90f8759309803b116b67a9371
show: add basic labels to work template

`hg show work` is much more usable if output is colored. This patch
implements coloring via label() in a very hacky way.

In a default Mercurial install, you'll see yellow node labels for all
phases. Branches and bookmarks use the same formatting as the commit
message. So this change doesn't help much in a default install. But if
you have a custom colors defined for these things, output is much more
readable.

The implementation obviously needs some work. But for a minor change
on a feature that isn't convered by BC, this seems like a clear win
for the feature in 4.2.

diff --git a/mercurial/templates/map-cmdline.show 
b/mercurial/templates/map-cmdline.show
--- a/mercurial/templates/map-cmdline.show
+++ b/mercurial/templates/map-cmdline.show
@@ -1,3 +1,9 @@
-# TODO add label() once we figure out which namespace the labels belong on.
+# TODO there are a few deficiencies in this file:
+# * Due to the way the file is loaded, references to other entities in the
+#   template doesn't work. That requires us to inline.
+# * The "namespace" of the labels needs to be worked out. We currently
+#   piggyback on existing values so color works.
+# * Obsolescence isn't considered for node labels. See _cset_labels in
+#   map-cmdline.default.
 showbookmarks = '{if(active, "*", " ")} {pad(bookmark, longestbookmarklen + 
4)}{shortest(node, 5)}\n'
-showwork = '{shortest(node, 5)}{if(branches, " ({branch})")}{if(bookmarks, " 
({bookmarks})")} {desc|firstline}'
+showwork = '{label("log.changeset changeset.{phase}", shortest(node, 
5))}{if(branches, " ({label("log.branch", branch)})")}{if(bookmarks, " 
({label("log.bookmarks", bookmarks)})")} {label("log.description", 
desc|firstline)}'
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 2] show: rename "underway" to "work"

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1492537786 25200
#  Tue Apr 18 10:49:46 2017 -0700
# Node ID d8d4b4acc68859f90f8759309803b116b67a9371
# Parent  ed42e00a5c4ec7a3bebaec699ef934429cdc2ddd
show: rename "underway" to "work"

Durham and I both like this better than "underway." We can add aliases
and bikeshed on the name during the 4.3 cycle, as this whole extension is
highly experimental.

diff --git a/hgext/show.py b/hgext/show.py
--- a/hgext/show.py
+++ b/hgext/show.py
@@ -189,8 +189,8 @@ def underwayrevset(repo, subset, x):
 
 return subset & relevant
 
-@showview('underway', fmtopic='underway')
-def showunderway(ui, repo, fm):
+@showview('work', fmtopic='work')
+def showwork(ui, repo, fm):
 """changesets that aren't finished"""
 # TODO support date-based limiting when calling revset.
 revs = repo.revs('sort(_underway(), topo)')
diff --git a/mercurial/templates/map-cmdline.show 
b/mercurial/templates/map-cmdline.show
--- a/mercurial/templates/map-cmdline.show
+++ b/mercurial/templates/map-cmdline.show
@@ -1,3 +1,3 @@
 # TODO add label() once we figure out which namespace the labels belong on.
 showbookmarks = '{if(active, "*", " ")} {pad(bookmark, longestbookmarklen + 
4)}{shortest(node, 5)}\n'
-showunderway = '{shortest(node, 5)}{if(branches, " ({branch})")}{if(bookmarks, 
" ({bookmarks})")} {desc|firstline}'
+showwork = '{shortest(node, 5)}{if(branches, " ({branch})")}{if(bookmarks, " 
({bookmarks})")} {desc|firstline}'
diff --git a/tests/test-show-underway.t b/tests/test-show-work.t
rename from tests/test-show-underway.t
rename to tests/test-show-work.t
--- a/tests/test-show-underway.t
+++ b/tests/test-show-work.t
@@ -8,27 +8,27 @@
 
 Command works on an empty repo
 
-  $ hg show underway
+  $ hg show work
 
 Single draft changeset shown
 
   $ echo 0 > foo
   $ hg -q commit -A -m 'commit 0'
 
-  $ hg show underway
+  $ hg show work
   @  9f171 commit 0
 
 Even when it isn't the wdir
 
   $ hg -q up null
 
-  $ hg show underway
+  $ hg show work
   o  9f171 commit 0
 
 Single changeset is still there when public because it is a head
 
   $ hg phase --public -r 0
-  $ hg show underway
+  $ hg show work
   o  9f171 commit 0
 
 A draft child will show both it and public parent
@@ -37,7 +37,7 @@ A draft child will show both it and publ
   $ echo 1 > foo
   $ hg commit -m 'commit 1'
 
-  $ hg show underway
+  $ hg show work
   @  181cc commit 1
   o  9f171 commit 0
 
@@ -46,7 +46,7 @@ Multiple draft children will be shown
   $ echo 2 > foo
   $ hg commit -m 'commit 2'
 
-  $ hg show underway
+  $ hg show work
   @  128c8 commit 2
   o  181cc commit 1
   o  9f171 commit 0
@@ -54,7 +54,7 @@ Multiple draft children will be shown
 Bumping first draft changeset to public will hide its parent
 
   $ hg phase --public -r 1
-  $ hg show underway
+  $ hg show work
   @  128c8 commit 2
   o  181cc commit 1
   |
@@ -67,7 +67,7 @@ Multiple DAG heads will be shown
   $ hg commit -m 'commit 3'
   created new head
 
-  $ hg show underway
+  $ hg show work
   @  f0abc commit 3
   | o  128c8 commit 2
   |/
@@ -79,7 +79,7 @@ Even when wdir is something else
 
   $ hg -q up null
 
-  $ hg show underway
+  $ hg show work
   o  f0abc commit 3
   | o  128c8 commit 2
   |/
@@ -94,7 +94,7 @@ Draft child shows public head (multiple 
   $ hg commit -m 'commit 4'
   created new head
 
-  $ hg show underway
+  $ hg show work
   @  668ca commit 4
   | o  f0abc commit 3
   | | o  128c8 commit 2
@@ -125,7 +125,7 @@ Branch name appears in output
   $ echo 4 > foo
   $ hg commit -m 'commit 4'
 
-  $ hg show underway
+  $ hg show work
   @  f8dd3 (mybranch) commit 4
   o  90cfc (mybranch) commit 3
   | o  128c8 commit 2
@@ -156,7 +156,7 @@ Bookmark name appears in output
   $ hg commit -m 'commit 4'
   $ hg bookmark mybook
 
-  $ hg show underway
+  $ hg show work
   @  cac82 (mybook) commit 4
   o  f0abc commit 3
   | o  128c8 (@) commit 2
diff --git a/tests/test-show.t b/tests/test-show.t
--- a/tests/test-show.t
+++ b/tests/test-show.t
@@ -11,7 +11,7 @@ No arguments shows available views
   available views:
   
   bookmarks -- bookmarks and their associated changeset
-  underway -- changesets that aren't finished
+  work -- changesets that aren't finished
   
   abort: no view requested
   (use "hg show VIEW" to choose a view)
@@ -40,7 +40,7 @@ No arguments shows available views
   
   bookmarks   bookmarks and their associated changeset
   
-  underwaychangesets that aren't finished
+  workchangesets that aren't finished
   
   (use 'hg help -e show' to show help for the show extension)
   
___
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/14/2017 01:04 AM, Durham Goode wrote:

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

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

[…]

*Practical example* (/simplified/):

   Situation:

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

   Way forward:

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

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


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

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


(note: I've purposely delay more "discussion" oriented part in my other 
email (that you also replied to) I'll reply to it too shortly after this 
one.)



In my example above, once "hg undo" is upstreamed, we are able to build 
a variant without hash preservation[1] and ship that the user by default 
without delay. Of course "hg undo" with hash salting is less nice than 
"hg undo" with hash preservation, but already much better than no "hg 
undo" at all.



To generalize, I've already heard about multiple interesting UI bits 
from Facebook that the community could benefit from (undo, ui focused on 
evolving orphans, etc). These UI does not strictly depends on 
contentious bits like hash preservation.


We can upstream and ship these bit while discussing more complex UI 
changes on the side[2]. These discussion will be simpler since less work 
will be "blocked" behind their conclusion. Having the feature variants 
in the wild will also gather data on user response and help

other developer to be more familiar with the topic of the discussion.
On a general principle, decoupling implementation discussion from UI 
polishing is usually a win.



I know you have the experience of external user in mind. But having this 
code upstream will also directly benefit Facebook operations. Your 
maintenance load would be lowered (one of the topic at the past sprint) 
and your divergence from the Core UI reduced.


Cheers,

[1] (For the sake of this example, we assume a world with 
hash-preservation blocking changeset-evolution plans)


[2] while keeping that discussion focused.

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

mercurial@32049: 6 new changesets

[Mercurial Commits]

6 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/cde72a195f32
changeset:   32044:cde72a195f32
user:Yuya Nishihara 
date:Mon Apr 17 23:53:19 2017 +0900
summary: dispatch: ignore further SIGPIPE while handling KeyboardInterrupt

https://www.mercurial-scm.org/repo/hg/rev/3eceeede26e9
changeset:   32045:3eceeede26e9
user:Yuya Nishihara 
date:Sat Feb 25 19:28:16 2017 +0900
summary: graphlog: optionally strip quotes from graphnode template (BC)

https://www.mercurial-scm.org/repo/hg/rev/5b630f2ccb4e
changeset:   32046:5b630f2ccb4e
user:Yuya Nishihara 
date:Sat Feb 25 19:32:39 2017 +0900
summary: commit: optionally strip quotes from commit template (BC)

https://www.mercurial-scm.org/repo/hg/rev/458f7294dfee
changeset:   32047:458f7294dfee
user:Yuya Nishihara 
date:Sat Feb 25 19:36:02 2017 +0900
summary: filemerge: optionally strip quotes from merge marker template (BC)

https://www.mercurial-scm.org/repo/hg/rev/c3ef33fd0058
changeset:   32048:c3ef33fd0058
user:Yuya Nishihara 
date:Thu Apr 13 22:27:25 2017 +0900
summary: progress: extract stubs to restart ferr.flush() and .write() on 
EINTR

https://www.mercurial-scm.org/repo/hg/rev/ed42e00a5c4e
changeset:   32049:ed42e00a5c4e
bookmark:@
tag: tip
user:Yuya Nishihara 
date:Thu Apr 13 22:31:17 2017 +0900
summary: progress: retry ferr.flush() and .write() on EINTR (issue5532)

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

mercurial@32043: 10 new changesets

[Mercurial Commits]

10 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/579bbcb4322b
changeset:   32034:579bbcb4322b
user:Yuya Nishihara 
date:Wed Apr 05 21:27:44 2017 +0900
summary: templatekw: eliminate unnecessary temporary variable 'names' from 
_showlist()

https://www.mercurial-scm.org/repo/hg/rev/f4ba33454b28
changeset:   32035:f4ba33454b28
user:Yuya Nishihara 
date:Wed Apr 05 21:32:32 2017 +0900
summary: templatekw: rename 'args' to 'mapping' in showlist()

https://www.mercurial-scm.org/repo/hg/rev/8bcc8c9b4e9f
changeset:   32036:8bcc8c9b4e9f
user:Yuya Nishihara 
date:Wed Apr 05 21:40:38 2017 +0900
summary: templatekw: change _showlist() to take mapping dict with no 
**kwargs expansion

https://www.mercurial-scm.org/repo/hg/rev/e5eab0fe69ee
changeset:   32037:e5eab0fe69ee
user:Yuya Nishihara 
date:Wed Apr 05 21:47:34 2017 +0900
summary: templatekw: have showlist() take mapping dict with no **kwargs 
expansion (API)

https://www.mercurial-scm.org/repo/hg/rev/3920b5970f95
changeset:   32038:3920b5970f95
user:Yuya Nishihara 
date:Wed Apr 05 21:57:05 2017 +0900
summary: templatekw: factor out showdict() helper

https://www.mercurial-scm.org/repo/hg/rev/2ab7578e685b
changeset:   32039:2ab7578e685b
user:Yuya Nishihara 
date:Sat Apr 15 10:51:17 2017 +0900
summary: templatefilters: fix crash by string formatting of '{x|splitlines}'

https://www.mercurial-scm.org/repo/hg/rev/0fb78cb90ca7
changeset:   32040:0fb78cb90ca7
user:Yuya Nishihara 
date:Sat Apr 15 12:58:06 2017 +0900
summary: dispatch: mark callcatch() as a private function

https://www.mercurial-scm.org/repo/hg/rev/38963a53ab0d
changeset:   32041:38963a53ab0d
user:Yuya Nishihara 
date:Sat Apr 15 13:02:34 2017 +0900
summary: dispatch: print traceback in scmutil.callcatch() if --traceback 
specified

https://www.mercurial-scm.org/repo/hg/rev/8f8ad0139b8b
changeset:   32042:8f8ad0139b8b
user:Yuya Nishihara 
date:Sat Apr 15 13:27:44 2017 +0900
summary: worker: propagate exit code to main process

https://www.mercurial-scm.org/repo/hg/rev/b844d0d367e2
changeset:   32043:b844d0d367e2
bookmark:@
tag: tip
user:Yuya Nishihara 
date:Sat Apr 15 13:04:55 2017 +0900
summary: worker: print traceback for uncaught exception unconditionally

-- 
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 4 of 4] worker: print traceback for uncaught exception unconditionally

[Kevin Bullock]

> On Apr 15, 2017, at 05:18, Yuya Nishihara  wrote:
> 
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1492229095 -32400
> #  Sat Apr 15 13:04:55 2017 +0900
> # Node ID 7c455aa99683ec6f7f24c24e11aaadfb3fe32fe3
> # Parent  535303fbc0cbdaa0c02a5aec441625c6e9b7b07d
> worker: print traceback for uncaught exception unconditionally

Queued, thanks.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

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

Re: [PATCH 6 of 5] templatefilters: fix crash by string formatting of '{x|splitlines}'

[Kevin Bullock]

> On Apr 16, 2017, at 08:27, Yuya Nishihara  wrote:
> 
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1492221077 -32400
> #  Sat Apr 15 10:51:17 2017 +0900
> # Node ID 9301c79b46ba6424585dd4ad0ec638b9be69de1b
> # Parent  3776ae7011f71bdc5e51be7cfd4219bf438ca384
> templatefilters: fix crash by string formatting of '{x|splitlines}'

Queued all 6 of these, thanks.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

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

Re: [PATCH 3 of 3] filemerge: optionally strip quotes from merge marker template (BC)

[Augie Fackler]

On Sat, Apr 15, 2017 at 07:51:33PM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1488018962 -32400
> #  Sat Feb 25 19:36:02 2017 +0900
> # Node ID aea294cf17416c162143292b8f6594fa33bab78b
> # Parent  51323898479b04d2063a880c9aecce116d83a6b9
> filemerge: optionally strip quotes from merge marker template (BC)

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

Re: [PATCH] dispatch: ignore further SIGPIPE while handling KeyboardInterrupt

[Augie Fackler]

On Tue, Apr 18, 2017 at 12:28:49AM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1492440799 -32400
> #  Mon Apr 17 23:53:19 2017 +0900
> # Node ID f2e785be58090ea271305ade6b744f0f7ee6344f
> # Parent  43ae8cb5a71cffe0aed48127e07c757fc642b2c0
> dispatch: ignore further SIGPIPE while handling KeyboardInterrupt

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

Re: [PATCH 2 of 2] progress: retry ferr.flush() and .write() on EINTR (issue5532)

[Augie Fackler]

On Sat, Apr 15, 2017 at 07:19:02PM +0900, Yuya Nishihara wrote:
> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1492090277 -32400
> #  Thu Apr 13 22:31:17 2017 +0900
> # Node ID 9de8286012a70e815978f595c28f13c28d72c266
> # Parent  087fef3472d6f204c8ef55c5257b9950aac35e72
> progress: retry ferr.flush() and .write() on EINTR (issue5532)

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

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

[Gregory Szorc]

On Fri, Apr 14, 2017 at 12:44 AM, Gregory Szorc 
wrote:

> # HG changeset patch
> # User Gregory Szorc 
> # Date 1492147168 25200
> #  Thu Apr 13 22:19:28 2017 -0700
> # Node ID 80bd24abcf67d5dc8b5f5bf83c796e1f71fc5bd9
> # Parent  283a95fe4ce5b91af4e2ed8ed1d3fe18ef3544bb
> tests: add tests for poorly behaving HTTP server
>
> I've spent several hours over the past few weeks investigating
> networking failures involving hg.mozilla.org. As part of this, it
> has become clear that the Mercurial client's error handling when
> it encounters network failures is far from robust.
>
> To prove this is true, I've devised a battery of tests simulating
> various network failures, notably premature connection closes. To
> achieve this, I've implemented an extension that monkeypatches the
> built-in HTTP server and hooks in at the socket level and allows
> various events to occur based on config options. For example, you
> can refuse to accept() a client socket or you can close() the socket
> after N bytes have been sent or received. The latter effectively
> simulates an unexpected connection drop (and these occur all the
> time in the real world).
>
> The new test file launches servers exhibiting various "bad" behaviors
> and points a client at them. As the many TODO comments in the test
> call attention to, Mercurial often displays unhelpful errors when
> network-related failures occur. This makes it difficult for users
> to understand what's going on and difficult for server administrators
> to pinpoint root causes without packet tracing.
>
> Upcoming patches will attempt to fix these error handling
> deficiencies.
>
> diff --git a/tests/badserverext.py b/tests/badserverext.py
> new file mode 100644
> --- /dev/null
> +++ b/tests/badserverext.py
> @@ -0,0 +1,269 @@
> +# badserverext.py - Extension making servers behave badly
> +#
> +# Copyright 2017 Gregory Szorc 
> +#
> +# This software may be used and distributed according to the terms of the
> +# GNU General Public License version 2 or any later version.
> +
> +# no-check-code
> +
> +"""Extension to make servers behave badly.
> +
> +This extension is useful for testing Mercurial behavior when various
> network
> +events occur.
> +
> +Various config options in the [badserver] section influence behavior:
> +
> +closebeforeaccept
> +   If true, close() the server socket when a new connection arrives before
> +   accept() is called. The server will then exit.
> +
> +closeafteraccept
> +   If true, the server will close() the client socket immediately after
> +   accept().
> +
> +closeafterrecvbytes
> +   If defined, close the client socket after receiving this many bytes.
> +
> +closeaftersendbytes
> +   If defined, close the client socket after sending this many bytes.
> +"""
> +
> +from __future__ import absolute_import
> +
> +import socket
> +
> +from mercurial.hgweb import (
> +server,
> +)
> +
> +# We can't adjust __class__ on a socket instance. So we define a proxy
> type.
> +class socketproxy(object):
> +__slots__ = (
> +'_orig',
> +'_logfp',
> +'_closeafterrecvbytes',
> +'_closeaftersendbytes',
> +)
> +
> +def __init__(self, obj, logfp, closeafterrecvbytes=0,
> + closeaftersendbytes=0):
> +object.__setattr__(self, '_orig', obj)
> +object.__setattr__(self, '_logfp', logfp)
> +object.__setattr__(self, '_closeafterrecvbytes',
> closeafterrecvbytes)
> +object.__setattr__(self, '_closeaftersendbytes',
> closeaftersendbytes)
> +
> +def __getattribute__(self, name):
> +if name in ('makefile',):
> +return object.__getattribute__(self, name)
> +
> +return getattr(object.__getattribute__(self, '_orig'), name)
> +
> +def __delattr__(self, name):
> +delattr(object.__getattribute__(self, '_orig'), name)
> +
> +def __setattr__(self, name, value):
> +setattr(object.__getattribute__(self, '_orig'), name, value)
> +
> +def makefile(self, mode, bufsize):
> +f = object.__getattribute__(self, '_orig').makefile(mode, bufsize)
> +
> +logfp = object.__getattribute__(self, '_logfp')
> +closeafterrecvbytes = object.__getattribute__(self,
> +
> '_closeafterrecvbytes')
> +closeaftersendbytes = object.__getattribute__(self,
> +
> '_closeaftersendbytes')
> +
> +return fileobjectproxy(f, logfp,
> +   closeafterrecvbytes=closeafterrecvbytes,
> +   closeaftersendbytes=closeaftersendbytes)
> +
> +# We can't adjust __class__ on socket._fileobject, so define a proxy.
> +class fileobjectproxy(object):
> +__slots__ = (
> +'_orig',
> +'_logfp',
> +'_closeafterrecvbytes',
> +'_closeaftersendbytes',
> +)
> +
> +def __init__(self, obj, logfp, closeafterrecvbytes=0,
> + closeaftersendbytes=0):
> +

Re: Hidden Commits in 4.3

[Denis Laxalde]

Durham Goode wrote:

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).



I think that exposing the feature to more users behind a config knob
might help moving forwards to more practical considerations, and
eventually let the opportunity to users missing abstract knowledge to
participate to the discussion (by "users", I mean: readers of this
thread or list in general, so probably not the whole community but more
than a handful of developers).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@32033: 30 new changesets

[Mercurial Commits]

30 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/bd3cb917761a
changeset:   32004:bd3cb917761a
user:Matt Harbison 
date:Fri Mar 31 23:00:41 2017 -0400
summary: hgwebdir: allow a repository to be hosted at "/"

https://www.mercurial-scm.org/repo/hg/rev/2406dbba49bd
changeset:   32005:2406dbba49bd
user:Matt Harbison 
date:Sat Apr 15 18:05:40 2017 -0400
summary: serve: add support for Mercurial subrepositories

https://www.mercurial-scm.org/repo/hg/rev/c84c83b5df0f
changeset:   32006:c84c83b5df0f
user:Pierre-Yves David 
date:Sat Apr 15 18:13:10 2017 +0200
summary: hidden: extract the code generating "filtered rev" error for 
wrapping

https://www.mercurial-scm.org/repo/hg/rev/f12b6185d435
changeset:   32007:f12b6185d435
user:Matt Harbison 
date:Sun Apr 16 00:29:38 2017 -0400
summary: testlib: move the prune alias into a shell script for Windows

https://www.mercurial-scm.org/repo/hg/rev/9a782e7e651e
changeset:   32008:9a782e7e651e
user:Matt Harbison 
date:Sun Apr 16 00:37:31 2017 -0400
summary: test-http: add a (glob) for Windows

https://www.mercurial-scm.org/repo/hg/rev/c6cb21ddf74a
changeset:   32009:c6cb21ddf74a
user:Pierre-Yves David 
date:Sat Apr 15 02:55:18 2017 +0200
summary: checkheads: upgrade the obsolescence postprocessing logic 
(issue4354)

https://www.mercurial-scm.org/repo/hg/rev/5622614e911c
changeset:   32010:5622614e911c
user:Pierre-Yves David 
date:Sat Apr 15 02:53:09 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case B2

https://www.mercurial-scm.org/repo/hg/rev/698623950bf5
changeset:   32011:698623950bf5
user:Pierre-Yves David 
date:Sat Apr 15 02:53:24 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case B4

https://www.mercurial-scm.org/repo/hg/rev/413c731f5475
changeset:   32012:413c731f5475
user:Pierre-Yves David 
date:Sat Apr 15 02:53:31 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case B5

https://www.mercurial-scm.org/repo/hg/rev/0cf4d6763735
changeset:   32013:0cf4d6763735
user:Pierre-Yves David 
date:Sat Apr 15 02:53:42 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case B6

https://www.mercurial-scm.org/repo/hg/rev/818cc18a7574
changeset:   32014:818cc18a7574
user:Pierre-Yves David 
date:Sat Apr 15 02:53:51 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case B7

https://www.mercurial-scm.org/repo/hg/rev/605c38105950
changeset:   32015:605c38105950
user:Pierre-Yves David 
date:Sat Apr 15 02:53:57 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case B8

https://www.mercurial-scm.org/repo/hg/rev/43c91eb53806
changeset:   32016:43c91eb53806
user:Pierre-Yves David 
date:Sat Apr 15 02:54:20 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case D3

https://www.mercurial-scm.org/repo/hg/rev/9f7ba0daada1
changeset:   32017:9f7ba0daada1
user:Pierre-Yves David 
date:Sat Apr 15 02:54:27 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case D5

https://www.mercurial-scm.org/repo/hg/rev/090fff9b6d65
changeset:   32018:090fff9b6d65
user:Pierre-Yves David 
date:Sat Apr 15 02:54:36 2017 +0200
summary: obsolescence: add test for the "branch replacement" logic during 
push, case D7

https://www.mercurial-scm.org/repo/hg/rev/bca8ad5c1256
changeset:   32019:bca8ad5c1256
user:Matt Harbison 
date:Sun Apr 16 20:59:14 2017 -0400
summary: test-tag: make hook runnable on Windows

https://www.mercurial-scm.org/repo/hg/rev/acc67cd7f508
changeset:   32020:acc67cd7f508
user:Matt Harbison 
date:Sun Apr 16 21:00:22 2017 -0400
summary: test-http-bad-server: conditionalize error output for Windows

https://www.mercurial-scm.org/repo/hg/rev/08e46fcb8637
changeset:   32021:08e46fcb8637
user:Matt Harbison 
date:Sun Apr 16 21:25:16 2017 -0400
summary: badserverext: explicitly flush each log write

https://www.mercurial-scm.org/repo/hg/rev/e5d7f99a3063
changeset:   

Re: [PATCH V4] hgwebdir: allow a repository to be hosted at "/"

[Yuya Nishihara]

On Mon, 17 Apr 2017 20:34:16 -0400, Matt Harbison wrote:
> On Mon, 17 Apr 2017 18:40:22 -0400, Sean Farley  wrote:
> 
> > Kevin Bullock  writes:
> >
> >>> On Apr 15, 2017, at 14:34, Matt Harbison  wrote:
> >>>
> >>> # HG changeset patch
> >>> # User Matt Harbison 
> >>> # Date 1491015641 14400
> >>> #  Fri Mar 31 23:00:41 2017 -0400
> >>> # Node ID 3fd50d5f9314a96f43eb73480763f224c4d05831
> >>> # Parent  4c2c30bc38b4f84ce8f215146bbf158e299065b3
> >>> hgwebdir: allow a repository to be hosted at "/"
> >>>
> >>> This can be useful in general, but will also be useful for hosting  
> >>> subrepos,
> >>> with the main repo at /.
> >>>
> >>> diff --git a/mercurial/hgweb/hgweb_mod.py  
> >>> b/mercurial/hgweb/hgweb_mod.py
> >>> --- a/mercurial/hgweb/hgweb_mod.py
> >>> +++ b/mercurial/hgweb/hgweb_mod.py
> >>> @@ -335,7 +335,7 @@
> >>> req.url = req.env['SCRIPT_NAME']
> >>> if not req.url.endswith('/'):
> >>> req.url += '/'
> >>> -if 'REPO_NAME' in req.env:
> >>> +if req.env.get('REPO_NAME'):
> >>
> >> Since we don't need the value returned from .get(), is there some other  
> >> reason for this change that I'm not seeing?
> >
> > 'REPO_NAME' is used in the next line, so I guess this was supposed to
> > be:
> >
> > foo = req.env.get('REPO_NAME')
> > if foo:
> > req.url += foo + '/'
> >
> > ?
> 
> Yeah, that's more clear.  A couple lines later also calls  
> "req.env.get('REPO_NAME')", so it's probably worth a local variable.
> 
> Without this check, links in index.html change like this:

We need to check the emptiness of the REPO_NAME string, not the existence
of the REPO_NAME key.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] color: also enable by default on windowso

[Yuya Nishihara]

On Mon, 17 Apr 2017 22:19:37 -0400, Josef 'Jeff' Sipek wrote:
> On Sun, Apr 16, 2017 at 02:55:27 +0200, Pierre-Yves David wrote:
> > # HG changeset patch
> > # User Pierre-Yves David 
> > # Date 1492302848 -7200
> > #  Sun Apr 16 02:34:08 2017 +0200
> > # Node ID 9d4f7de0a25c91103f6419c4675bcb21ad7c5098
> > # Parent  7ec1415a4de91a5c56e549cd4a40cb8e9411f8d9
> > # EXP-Topic color
> > # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
> > #  hg pull 
> > https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r 9d4f7de0a25c
> > color: also enable by default on windowso
> 
> Typo in "windows".

Doh, fixed in flight.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 3] color: turn on by default (but for windows)

[Yuya Nishihara]

On Mon, 17 Apr 2017 20:44:16 +0200, Pierre-Yves David wrote:
> > hgext/color.py can also be removed
> > and marked as a builtin, but that isn't important.
> 
> I wanted to mimize the possible churn on stable if we have to backout 
> the change in default during the freeze. My plan is to clan this up 
> early in the 4.3 cycle if the changes survive in the 4.2 release.

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

Re: [PATCH] color: update the help with the new default

[Yuya Nishihara]

On Mon, 17 Apr 2017 20:40:56 +0200, Pierre-Yves David wrote:
> # HG changeset patch
> # User Pierre-Yves David 
> # Date 1492453320 -7200
> #  Mon Apr 17 20:22:00 2017 +0200
> # Node ID dea9816832a37b9e310051841b307fba0138e45d
> # Parent  43ae8cb5a71cffe0aed48127e07c757fc642b2c0
> # EXP-Topic color
> # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
> #  hg pull 
> https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r dea9816832a3
> color: update the help with the new default

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

[PATCH remotenames-ext] remotenames: be compatible with upstream change about scmutil.vfs

[Kostia Balytskyi]

# HG changeset patch
# User Kostia Balytskyi 
# Date 1492508238 25200
#  Tue Apr 18 02:37:18 2017 -0700
# Node ID b55f98398522d9c7cf81ab191ddd322926699b0a
# Parent  4f17d4ae821e7654b3c134002537155b28f7e146
remotenames: be compatible with upstream change about scmutil.vfs

scmutil.vfs is now vfs.vfs and usage of the former causes deprecation
warnings.

diff --git a/remotenames.py b/remotenames.py
--- a/remotenames.py
+++ b/remotenames.py
@@ -39,6 +39,7 @@ from mercurial import scmutil
 from mercurial import templatekw
 from mercurial import url
 from mercurial import util
+from mercurial import vfs as vfsmod
 from mercurial.i18n import _
 from mercurial.node import hex, short, bin, nullid
 from hgext import schemes
@@ -1376,7 +1377,7 @@ def joinremotename(remote, ref):
 
 def shareawarevfs(repo):
 if repo.shared():
-return scmutil.vfs(repo.sharedpath)
+return vfsmod.vfs(repo.sharedpath)
 else:
 return repo.vfs
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel