D3830: rebase: suppress transaction warns during dry-run

[khanchi97 (Sushil khanchi)]

khanchi97 updated this revision to Diff 9593.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3830?vs=9501&id=9593

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

AFFECTED FILES
  hgext/rebase.py
  mercurial/localrepo.py
  mercurial/transaction.py
  tests/test-rebase-inmemory.t

CHANGE DETAILS

diff --git a/tests/test-rebase-inmemory.t b/tests/test-rebase-inmemory.t
--- a/tests/test-rebase-inmemory.t
+++ b/tests/test-rebase-inmemory.t
@@ -284,8 +284,6 @@
   rebasing 3:055a42cdd887 "d"
   rebasing 4:e860deea161a "e"
   merging e
-  transaction abort!
-  rollback completed
   hit a merge conflict
   [1]
   $ hg diff
diff --git a/mercurial/transaction.py b/mercurial/transaction.py
--- a/mercurial/transaction.py
+++ b/mercurial/transaction.py
@@ -105,7 +105,7 @@
 class transaction(util.transactional):
 def __init__(self, report, opener, vfsmap, journalname, undoname=None,
  after=None, createmode=None, validator=None, releasefn=None,
- checkambigfiles=None, name=r''):
+ checkambigfiles=None, name=r'', suppwarns=False):
 """Begin a new transaction
 
 Begins a new transaction that allows rolling back writes in the event 
of
@@ -133,6 +133,7 @@
 self.map = {}
 self.journal = journalname
 self.undoname = undoname
+self.suppwarns = suppwarns
 self._queue = []
 # A callback to validate transaction content before closing it.
 # should raise exception is anything is wrong.
@@ -570,7 +571,8 @@
 self.opener.unlink(self.journal)
 return
 
-self.report(_("transaction abort!\n"))
+if not self.suppwarns:
+self.report(_("transaction abort!\n"))
 
 try:
 for cat in sorted(self._abortcallback):
@@ -580,7 +582,8 @@
 _playback(self.journal, self.report, self.opener, self._vfsmap,
   self.entries, self._backupentries, False,
   checkambigfiles=self.checkambigfiles)
-self.report(_("rollback completed\n"))
+if not self.suppwarns:
+self.report(_("rollback completed\n"))
 except BaseException:
 self.report(_("rollback failed - please run hg recover\n"))
 finally:
diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -1224,7 +1224,7 @@
 return tr
 return None
 
-def transaction(self, desc, report=None):
+def transaction(self, desc, report=None, supptrwarns=False):
 if (self.ui.configbool('devel', 'all-warnings')
 or self.ui.configbool('devel', 'check-locks')):
 if self._currentlock(self._lockref) is None:
@@ -1371,7 +1371,8 @@
  validator=validate,
  releasefn=releasefn,
  checkambigfiles=_cachedfiles,
- name=desc)
+ name=desc,
+ suppwarns=supptrwarns)
 tr.changes['revs'] = xrange(0, 0)
 tr.changes['obsmarkers'] = set()
 tr.changes['phases'] = {}
diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -864,7 +864,7 @@
 overrides = {('rebase', 'singletransaction'): True}
 with ui.configoverride(overrides, 'rebase'):
 _origrebase(ui, repo, opts, rbsrt, inmemory=True,
-leaveunfinished=True)
+leaveunfinished=True, supptrwarns=True)
 except error.InMemoryMergeConflictsError:
 ui.status(_('hit a merge conflict\n'))
 if confirm:
@@ -898,7 +898,8 @@
 rbsrt = rebaseruntime(repo, ui, inmemory, opts)
 return _origrebase(ui, repo, opts, rbsrt, inmemory=inmemory)
 
-def _origrebase(ui, repo, opts, rbsrt, inmemory=False, leaveunfinished=False):
+def _origrebase(ui, repo, opts, rbsrt, inmemory=False, leaveunfinished=False,
+supptrwarns=False):
 with repo.wlock(), repo.lock():
 # Validate input and define rebasing points
 destf = opts.get('dest', None)
@@ -955,7 +956,7 @@
 
 singletr = ui.configbool('rebase', 'singletransaction')
 if singletr:
-tr = repo.transaction('rebase')
+tr = repo.transaction('rebase', supptrwarns=supptrwarns)
 
 # If `rebase.singletransaction` is enabled, wrap the entire operation 
in
 # one transaction here. Otherwise, transactions are obtained when



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

D3871: rebase: improve output of --confirm option

[khanchi97 (Sushil khanchi)]

khanchi97 added a comment.


  In https://phab.mercurial-scm.org/D3871#61439, @durin42 wrote:
  
  > This doesn't apply cleanly, could you rebase it?
  
  
  @durin42 I have made a change in --confirm option 
https://phab.mercurial-scm.org/D3944 if this functionality (don't prompt if hit 
a conflict) is acceptable then we don't need this patch (i.e suppressing rebase 
info). Thanks!

INLINE COMMENTS

> durin42 wrote in rebase.py:975
> I feel like the functions that accept supprbinfo should grow a docstring or 
> comment that explains what supprbinfo does.
> 
> (I sort of figured it out, but it took a while.)

yeah, next time I will take care of this.

REPOSITORY
  rHG Mercurial

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

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

D3944: rebase: in --confirm option just abort if hit a conflict

[khanchi97 (Sushil khanchi)]

khanchi97 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  Before this patch, it was prompting the user in both cases 1) when
  there is no conflict 2) when there is atleast one conlict. But
  for simplicity we can just abort if we hit a conflict and no need to
  prompt in that case.

REPOSITORY
  rHG Mercurial

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

AFFECTED FILES
  hgext/rebase.py
  tests/test-rebase-inmemory.t

CHANGE DETAILS

diff --git a/tests/test-rebase-inmemory.t b/tests/test-rebase-inmemory.t
--- a/tests/test-rebase-inmemory.t
+++ b/tests/test-rebase-inmemory.t
@@ -472,14 +472,11 @@
   o  0:cb9a9f314b8b test
  a
   
-  $ hg rebase -s 4 -d . --keep --config ui.interactive=True --confirm << EOF
-  > n
-  > EOF
+  $ hg rebase -s 4 -d . --keep --confirm
   starting in-memory rebase
   rebasing 4:e860deea161a "e"
   merging e
   hit a merge conflict
-  apply changes (yn)? n
   [1]
   $ hg log -G --template "{rev}:{short(node)} 
{person(author)}\n{firstline(desc)} {topic}\n\n"
   @  9:906d72f66a59 test
@@ -512,58 +509,3 @@
   o  0:cb9a9f314b8b test
  a
   
-
-  $ hg rebase -s 4 -d . --keep --config ui.interactive=True --confirm << EOF
-  > y
-  > EOF
-  starting in-memory rebase
-  rebasing 4:e860deea161a "e"
-  merging e
-  hit a merge conflict
-  apply changes (yn)? y
-  rebasing 4:e860deea161a "e"
-  merging e
-  warning: conflicts while merging e! (edit, then use 'hg resolve --mark')
-  unresolved conflicts (see hg resolve, then hg rebase --continue)
-  [1]
-
-  $ echo e>e
-  $ hg resolve --mark --all
-  (no more unresolved files)
-  continue: hg rebase --continue
-  $ hg rebase --continue
-  rebasing 4:e860deea161a "e"
-  $ hg log -G --template "{rev}:{short(node)} 
{person(author)}\n{firstline(desc)} {topic}\n\n"
-  o  10:9fa3731dd6df test
-  |  e
-  |
-  @  9:906d72f66a59 test
-  |  conflict with e
-  |
-  o  8:12cbf031f469 test
-  |  d
-  |
-  o  7:c83b1da5b1ae test
-  |  c
-  |
-  o  6:baf10c5166d4 test
-  |  g
-  |
-  o  5:6343ca3eff20 test
-  |  f
-  |
-  | o  4:e860deea161a test
-  | |  e
-  | |
-  | o  3:055a42cdd887 test
-  | |  d
-  | |
-  | o  2:177f92b77385 test
-  |/   c
-  |
-  o  1:d2ae7f538514 test
-  |  b
-  |
-  o  0:cb9a9f314b8b test
- a
-  
diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -872,9 +872,6 @@
 rbsrt._prepareabortorcontinue(isabort=True, backup=False,
   suppwarns=True)
 needsabort = False
-if not ui.promptchoice(_(b'apply changes (yn)?'
- b'$$ &Yes $$ &No')):
-return _dorebase(ui, repo, opts, inmemory=False)
 return 1
 else:
 if confirm:



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

[PATCH 1 of 2] phases: remove excessive optimization from newheads() (issue5939)

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1531541958 -32400
#  Sat Jul 14 13:19:18 2018 +0900
# Node ID c8f181c48ae26247478aea82c8d2ab2f886831f9
# Parent  d5b851a39710f8415f98575e4f00396fe7ee2809
phases: remove excessive optimization from newheads() (issue5939)

This function is intended to compute 'heads(::heads - roots::)', but it
failed because 'heads + parents(roots)' missed sibling branches of the roots.
That's why the public heads slipped down from D to B in the example added by
2a227782e754 "tests: add test demonstrating phase loss when cloning":

  > Edraft
  > |\Z  draft
  > | Y  draft
  > D |  public
  > | X  draft
  > C/   public
  > Bpublic
  > Apublic
  where heads = {E, Z},
roots = {X}

diff --git a/mercurial/phases.py b/mercurial/phases.py
--- a/mercurial/phases.py
+++ b/mercurial/phases.py
@@ -665,8 +665,7 @@ def newheads(repo, heads, roots):
 * `heads`: define the first subset
 * `roots`: define the second we subtract from the first"""
 repo = repo.unfiltered()
-revset = repo.set('heads((%ln + parents(%ln)) - (%ln::%ln))',
-  heads, roots, roots, heads)
+revset = repo.set('heads(::%ln - (%ln::%ln))', heads, roots, heads)
 return [c.node() for c in revset]
 
 
diff --git a/tests/test-phases-exchange.t b/tests/test-phases-exchange.t
--- a/tests/test-phases-exchange.t
+++ b/tests/test-phases-exchange.t
@@ -1478,7 +1478,8 @@ Works with default settings
   $ killdaemons.py
 
 With legacy listkeys over bundle2
-TODO issue 5939: public phase lost on 26805 and f5853
+(issue 5939: public phase was lost on 26805 and f5853 before, due to a bug
+of phase heads computation)
 
   $ hg -R mergetest --config devel.legacy.exchange=phases serve -p $HGPORT -d 
--pid-file=hg.pid
   $ cat hg.pid >> $DAEMON_PIDS
@@ -1492,9 +1493,9 @@ TODO issue 5939: public phase lost on 26
   new changesets 426bada5c675:bb94757e651a
   test-debug-phase: new rev 0:  x -> 0
   test-debug-phase: new rev 1:  x -> 0
-  test-debug-phase: new rev 2:  x -> 1
+  test-debug-phase: new rev 2:  x -> 0
   test-debug-phase: new rev 3:  x -> 1
-  test-debug-phase: new rev 4:  x -> 1
+  test-debug-phase: new rev 4:  x -> 0
   test-debug-phase: new rev 5:  x -> 1
   test-debug-phase: new rev 6:  x -> 1
   test-debug-phase: new rev 7:  x -> 1
@@ -1506,11 +1507,11 @@ TODO issue 5939: public phase lost on 26
   |/|
   o |  13b7b draft
   | |
-  | o  f5853 draft
+  | o  f5853 public
   | |
   o |  c67c4 draft
   | |
-  | o  26805 draft
+  | o  26805 public
   |/
   o  11247 public
   |
@@ -1519,7 +1520,8 @@ TODO issue 5939: public phase lost on 26
   $ killdaemons.py
 
 Without bundle2
-TODO issue 5939: public phase lost on 26805 and f5853
+(issue 5939: public phase was lost on 26805 and f5853 before, due to a bug
+of phase heads computation)
 
   $ hg -R mergetest serve -p $HGPORT -d --pid-file=hg.pid
   $ cat hg.pid >> $DAEMON_PIDS
@@ -1533,9 +1535,9 @@ TODO issue 5939: public phase lost on 26
   new changesets 426bada5c675:bb94757e651a
   test-debug-phase: new rev 0:  x -> 0
   test-debug-phase: new rev 1:  x -> 0
-  test-debug-phase: new rev 2:  x -> 1
+  test-debug-phase: new rev 2:  x -> 0
   test-debug-phase: new rev 3:  x -> 1
-  test-debug-phase: new rev 4:  x -> 1
+  test-debug-phase: new rev 4:  x -> 0
   test-debug-phase: new rev 5:  x -> 1
   test-debug-phase: new rev 6:  x -> 1
   test-debug-phase: new rev 7:  x -> 1
@@ -1547,11 +1549,11 @@ TODO issue 5939: public phase lost on 26
   |/|
   o |  13b7b draft
   | |
-  | o  f5853 draft
+  | o  f5853 public
   | |
   o |  c67c4 draft
   | |
-  | o  26805 draft
+  | o  26805 public
   |/
   o  11247 public
   |
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Discussion about Mercurial 4.8 Sprint

[Yuya Nishihara]

On Fri, 13 Jul 2018 20:33:19 -0700, Sean Farley wrote:
> 
> Martin von Zweigbergk  writes:
> 
> > On Fri, Jul 13, 2018, 00:32 Sean Farley  wrote:
> >
> >>
> >> Martin von Zweigbergk  writes:
> >>
> >> > On Thu, Jul 12, 2018 at 9:11 PM Sean Farley  wrote:
> >> >
> >> >>
> >> >> Martin von Zweigbergk  writes:
> >> >>
> >> >> > On Thu, Jul 12, 2018, 17:41 Sean Farley  wrote:
> >> >> >
> >> >> >>
> >> >> >> Martin von Zweigbergk via Mercurial-devel <
> >> >> >> mercurial-devel@mercurial-scm.org> writes:
> >> >> >>
> >> >> >> > Since there was no consensus in this thread, we discussed it in the
> >> >> >> > steering committee. We decided to do it in Europe this time (i.e.
> >> the
> >> >> 4.8
> >> >> >> > sprint) since everyone indicated that they could make it there. We
> >> >> also
> >> >> >> > decided to do it Oct 12-14 and to do it in Stockholm. I'll send a
> >> >> >> separate
> >> >> >> > email to the list about that.
> >> >> >>
> >> >> >> I guess I'm really confused about this. In this thread, many people,
> >> >> >> myself included, offered to help and even began the process of
> >> securing
> >> >> >> a meeting location.
> >> >> >>
> >> >> >> Could you please provide insight on how the decision was made? Were
> >> >> >> venue offers made privately?
> >> >> >>
> >> >> >
> >> >> > No offers made privately (why do you ask?), the offers we had were on
> >> the
> >> >> > wiki. Those offers were Tokyo, Lyon, and Stockholm. According to the
> >> >> > availability table, everyone was able to come to Europe, but not
> >> everyone
> >> >> > could make it to Asia, so we decided not to do it in Tokyo this time.
> >> The
> >> >> > Lyon location was an hour or two further away from most locations and
> >> the
> >> >> > Stockholm location (except from France, of course). So I proposed
> >> doing
> >> >> it
> >> >> > in Stockholm and no one objected.
> >> >>
> >> >> In this thread, we talked and made plans so far for some place in France
> >> >> (either Paris or Lyon). The wiki page you mentioned is an opt-in only
> >> >> notification and I haven't edited that page nor was I subscribed which
> >> >> is why I asked about private offers. Not everyone on this mailing list
> >> >> got those notifications... so, of course, no one objected because not
> >> >> many of us even knew Stockholm was a serious contender.
> >> >>
> >> >
> >> > I updated this thread saying that we'd updated wiki with availability for
> >> > Tokyo and Stockholm. There wasn't much more than a mention of Lyon and
> >> > Paris either, so I don't know why Stockholm would be less serious.
> >> >
> >> >
> >> >> It feels like a decision was made without involving the rest of the
> >> >> community that was already discussing this sprint.
> >> >>
> >> >
> >> > I can understand that it felt that way, and I'm sorry about that. I
> >> suppose
> >> > we could have decided only between Asia and Europe to start with and then
> >> > updated the Availability table on the wiki to have Lyon/Stockholm columns
> >> > instead (Paris didn't seem realistic given the small space). That would
> >> > clearly have delayed the decision (by a week? two?), but perhaps that
> >> would
> >> > have been fine given that the sprint ended up being quite late in the
> >> fall
> >> > this time. At least I (I don't know about others) felt like it was better
> >> > to decide something than to hear everyone's point of view, because I had
> >> a
> >> > feeling we would not reach consensus even if we did.
> >>
> >> I understand the need to make a decision. But this was making a decision
> >> without presenting a clear timeline nor even presenting, you know, an
> >> email saying what you just said above: that you're about to make a
> >> decision and here are your current thoughts.
> >>
> >
> > I agree, that would have been fair. We should have sent a notification to
> > this thread with something like "This thread is not making progress, so the
> > steering committee will decide on a location and time". That message should
> > also have been clear that we were going to decide on an exact location, not
> > just a continent, so people could provide more specific comments about
> > that.
> 
> I understand that email communication can be difficult but I am
> disheartened by your response. It dismisses my work and all the
> volunteers in this thread by ignoring the progress we made. All I wanted
> from this thread was for the committee to engage in a positive way with
> the community. To tell all the community members I've met in my time
> that it is worth it to volunteer.
> 
> I don't believe all is lost, though.

I just thank Kyle for planning Tokyo sprint, which was dismissed btw, you for
bringing up invisible concerns about Asia sprint, Marla, Arthur and Martin
for finding alternative places in Europe.

> > I don't think we'd heard anything more specific than "I prefer
> > Europe" or "I prefer Asia" in this thread (or on the wiki), except that it
> > was pretty clear that Kyle preferred Tokyo (or

[PATCH 2 of 2] phases: micro-optimize newheads() to not create context objects

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1531542109 -32400
#  Sat Jul 14 13:21:49 2018 +0900
# Node ID 503d14253b22603b1f76c80dd6b89b6ebcfe5e06
# Parent  c8f181c48ae26247478aea82c8d2ab2f886831f9
phases: micro-optimize newheads() to not create context objects

diff --git a/mercurial/phases.py b/mercurial/phases.py
--- a/mercurial/phases.py
+++ b/mercurial/phases.py
@@ -665,9 +665,8 @@ def newheads(repo, heads, roots):
 * `heads`: define the first subset
 * `roots`: define the second we subtract from the first"""
 repo = repo.unfiltered()
-revset = repo.set('heads(::%ln - (%ln::%ln))', heads, roots, heads)
-return [c.node() for c in revset]
-
+revs = repo.revs('heads(::%ln - (%ln::%ln))', heads, roots, heads)
+return pycompat.maplist(repo.changelog.node, revs)
 
 def newcommitphase(ui):
 """helper to get the target phase of new commit
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D3933: pullbundle: fix handling of gzip bundlespecs

[joerg.sonnenberger (Joerg Sonnenberger)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG7e4a856a4f05: pullbundle: fix handling of gzip bundlespecs 
(authored by joerg.sonnenberger, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3933?vs=9569&id=9591

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

AFFECTED FILES
  mercurial/wireprotov1server.py
  tests/test-pull-bundle.t

CHANGE DETAILS

diff --git a/tests/test-pull-bundle.t b/tests/test-pull-bundle.t
--- a/tests/test-pull-bundle.t
+++ b/tests/test-pull-bundle.t
@@ -46,9 +46,9 @@
   $ hg bundle --base 1 -r 2 .hg/2.hg
   1 changesets found
   $ cat < .hg/pullbundles.manifest
-  > 2.hg heads=effea6de0384e684f44435651cb7bd70b8735bd4 
bases=bbd179dfa0a71671c253b3ae0aa1513b60d199fa
-  > 1.hg heads=ed1b79f46b9a29f5a6efa59cf12fcfca43bead5a 
bases=bbd179dfa0a71671c253b3ae0aa1513b60d199fa
-  > 0.hg heads=bbd179dfa0a71671c253b3ae0aa1513b60d199fa
+  > 2.hg BUNDLESPEC=none-v2 heads=effea6de0384e684f44435651cb7bd70b8735bd4 
bases=bbd179dfa0a71671c253b3ae0aa1513b60d199fa
+  > 1.hg BUNDLESPEC=bzip2-v2 heads=ed1b79f46b9a29f5a6efa59cf12fcfca43bead5a 
bases=bbd179dfa0a71671c253b3ae0aa1513b60d199fa
+  > 0.hg BUNDLESPEC=gzip-v2 heads=bbd179dfa0a71671c253b3ae0aa1513b60d199fa
   > EOF
   $ hg --config blackbox.track=debug --debug serve -p $HGPORT2 -d 
--pid-file=../repo.pid
   listening at http://*:$HGPORT2/ (bound to $LOCALIP:$HGPORT2) (glob) (?)
diff --git a/mercurial/wireprotov1server.py b/mercurial/wireprotov1server.py
--- a/mercurial/wireprotov1server.py
+++ b/mercurial/wireprotov1server.py
@@ -353,7 +353,9 @@
 common_anc = cl.ancestors([cl.rev(rev) for rev in common], inclusive=True)
 compformats = clientcompressionsupport(proto)
 for entry in res:
-if 'COMPRESSION' in entry and entry['COMPRESSION'] not in compformats:
+comp = entry.get('COMPRESSION')
+altcomp = util.compengines._bundlenames.get(comp)
+if comp and comp not in compformats and altcomp not in compformats:
 continue
 # No test yet for VERSION, since V2 is supported by any client
 # that advertises partial pulls



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

Re: Discussion about Mercurial 4.8 Sprint

[Sean Farley]

Augie Fackler  writes:

>> On Jul 13, 2018, at 09:29, Martin von Zweigbergk via Mercurial-devel 
>>  wrote:
>>
>> We took people's voices into account. That's why we choose Europe over Asia 
>> (it felt like people on the committee generally preferred Tokyo). But again, 
>> I agree that we should have been more transparent.
>
> Yep, sorry about the lack of transparency. I think we all burned out on the 
> "all the voices" thread and just decided to decide.

I am sorry you and other from the committee feel burned out. I was
hoping the response I received would be warm and engaging, and not
dismissive or imply that my offer to help was just another complaint. I
am saddened by this response from you / the committee. I would have
liked to thought it was an interesting thread that got more community
members involved that otherwise wouldn't.

In the beginning of this thread you said, "so far I'm seeing complaints
without alternatives" ... ok, so I asked people to help out and start
looking for venues. But it doesn't seem that was enough?

The last few emails from you and Martin have read to me as you both feel
there is nothing to be done. It's very confusing to get a message of
urgency and such a finalized stance from you / the committee yet we have
three months until the next proposed sprint.

I don't see it as irreparable, though. I think the committee could (and
should) go out of their way to repair these strained relations. We have
three months. Why not engage with and coordinate with the people that
have volunteered? Nothing is tying us to host in Stockholm. Now is the
chance to really show that there are people here who are willing to help
the community.

Unfortunately, the message I'm getting is to not bother, though I'd love
to be proven wrong.

> (One other thing that came up, by way of transparency: we'd like to try and 
> plan the spring 2019 sprint somewhat soon, with an eye towards pulling off 
> the Asia-based sprint we've talked about for something like 3 years. I think 
> it'd be nice to get Asia into the rotation, as we might see some new faces.)

I wish you luck. My attempts to engage people and get them involved in
the community were unsuccessful and have depleted me of volunteering
energy. For now, I'll take the weekend off and contemplate on how I can
help the community in other ways.


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

Re: Discussion about Mercurial 4.8 Sprint

[Sean Farley]

Martin von Zweigbergk  writes:

> On Fri, Jul 13, 2018, 00:32 Sean Farley  wrote:
>
>>
>> Martin von Zweigbergk  writes:
>>
>> > On Thu, Jul 12, 2018 at 9:11 PM Sean Farley  wrote:
>> >
>> >>
>> >> Martin von Zweigbergk  writes:
>> >>
>> >> > On Thu, Jul 12, 2018, 17:41 Sean Farley  wrote:
>> >> >
>> >> >>
>> >> >> Martin von Zweigbergk via Mercurial-devel <
>> >> >> mercurial-devel@mercurial-scm.org> writes:
>> >> >>
>> >> >> > Since there was no consensus in this thread, we discussed it in the
>> >> >> > steering committee. We decided to do it in Europe this time (i.e.
>> the
>> >> 4.8
>> >> >> > sprint) since everyone indicated that they could make it there. We
>> >> also
>> >> >> > decided to do it Oct 12-14 and to do it in Stockholm. I'll send a
>> >> >> separate
>> >> >> > email to the list about that.
>> >> >>
>> >> >> I guess I'm really confused about this. In this thread, many people,
>> >> >> myself included, offered to help and even began the process of
>> securing
>> >> >> a meeting location.
>> >> >>
>> >> >> Could you please provide insight on how the decision was made? Were
>> >> >> venue offers made privately?
>> >> >>
>> >> >
>> >> > No offers made privately (why do you ask?), the offers we had were on
>> the
>> >> > wiki. Those offers were Tokyo, Lyon, and Stockholm. According to the
>> >> > availability table, everyone was able to come to Europe, but not
>> everyone
>> >> > could make it to Asia, so we decided not to do it in Tokyo this time.
>> The
>> >> > Lyon location was an hour or two further away from most locations and
>> the
>> >> > Stockholm location (except from France, of course). So I proposed
>> doing
>> >> it
>> >> > in Stockholm and no one objected.
>> >>
>> >> In this thread, we talked and made plans so far for some place in France
>> >> (either Paris or Lyon). The wiki page you mentioned is an opt-in only
>> >> notification and I haven't edited that page nor was I subscribed which
>> >> is why I asked about private offers. Not everyone on this mailing list
>> >> got those notifications... so, of course, no one objected because not
>> >> many of us even knew Stockholm was a serious contender.
>> >>
>> >
>> > I updated this thread saying that we'd updated wiki with availability for
>> > Tokyo and Stockholm. There wasn't much more than a mention of Lyon and
>> > Paris either, so I don't know why Stockholm would be less serious.
>> >
>> >
>> >> It feels like a decision was made without involving the rest of the
>> >> community that was already discussing this sprint.
>> >>
>> >
>> > I can understand that it felt that way, and I'm sorry about that. I
>> suppose
>> > we could have decided only between Asia and Europe to start with and then
>> > updated the Availability table on the wiki to have Lyon/Stockholm columns
>> > instead (Paris didn't seem realistic given the small space). That would
>> > clearly have delayed the decision (by a week? two?), but perhaps that
>> would
>> > have been fine given that the sprint ended up being quite late in the
>> fall
>> > this time. At least I (I don't know about others) felt like it was better
>> > to decide something than to hear everyone's point of view, because I had
>> a
>> > feeling we would not reach consensus even if we did.
>>
>> I understand the need to make a decision. But this was making a decision
>> without presenting a clear timeline nor even presenting, you know, an
>> email saying what you just said above: that you're about to make a
>> decision and here are your current thoughts.
>>
>
> I agree, that would have been fair. We should have sent a notification to
> this thread with something like "This thread is not making progress, so the
> steering committee will decide on a location and time". That message should
> also have been clear that we were going to decide on an exact location, not
> just a continent, so people could provide more specific comments about
> that.

I understand that email communication can be difficult but I am
disheartened by your response. It dismisses my work and all the
volunteers in this thread by ignoring the progress we made. All I wanted
from this thread was for the committee to engage in a positive way with
the community. To tell all the community members I've met in my time
that it is worth it to volunteer.

I don't believe all is lost, though.

> I don't think we'd heard anything more specific than "I prefer
> Europe" or "I prefer Asia" in this thread (or on the wiki), except that it
> was pretty clear that Kyle preferred Tokyo (or at least Japan in general).
> Thanks for the feedback. We'll try to do better next time.

I thought my offers and that of the others qualified as more than
complaints or "I prefer Europe." I've offered to help. Marla offered to
help. A lot of people spoke up for trying to make something work in
France ... yet, Stockholm was chosen?

It doesn't add up to me. And I very much hope you see how rude this
comes off for community members that thought they could try a

[PATCH 1 of 2] cext: reformat with clang-format 6.0

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1531533010 -32400
#  Sat Jul 14 10:50:10 2018 +0900
# Node ID 42bce1d7778658cae95ec0a2aa29ff72d503c000
# Parent  2a227782e75426a3e4408273a9a4eebe79dfdcea
cext: reformat with clang-format 6.0

It appears some changes in clang-format affect our code. I didn't dig into
that deeper since the new output looks better.

diff --git a/mercurial/cext/pathencode.c b/mercurial/cext/pathencode.c
--- a/mercurial/cext/pathencode.c
+++ b/mercurial/cext/pathencode.c
@@ -474,7 +474,10 @@ static Py_ssize_t basicencode(char *dest
static const uint32_t twobytes[8] = {0, 0, 0x87fe};
 
static const uint32_t onebyte[8] = {
-   1, 0x2bff3bfa, 0x6801, 0x2fff,
+   1,
+   0x2bff3bfa,
+   0x6801,
+   0x2fff,
};
 
Py_ssize_t destlen = 0;
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2] hghave: require clang-format >= 6 due to output change

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1531533112 -32400
#  Sat Jul 14 10:51:52 2018 +0900
# Node ID d5b851a39710f8415f98575e4f00396fe7ee2809
# Parent  42bce1d7778658cae95ec0a2aa29ff72d503c000
hghave: require clang-format >= 6 due to output change

diff --git a/tests/hghave.py b/tests/hghave.py
--- a/tests/hghave.py
+++ b/tests/hghave.py
@@ -452,8 +452,9 @@ def has_pylint():
 
 @check("clang-format", "clang-format C code formatter")
 def has_clang_format():
-return matchoutput("clang-format --help",
-   br"^OVERVIEW: A tool to format C/C\+\+[^ ]+ code.")
+m = matchoutput('clang-format --version', br'clang-format version (\d)')
+# style changed somewhere between 4.x and 6.x
+return m and int(m.group(1)) >= 6
 
 @check("jshint", "JSHint static code analysis tool")
 def has_jshint():
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: D3919: grep: restore pre-9ef10437bb88 behavior, enable wdir search by tweakdefaults

[Yuya Nishihara]

(resend)

> So what's the next step should be ?

Maybe add support for "--all-files -rMULTIREV" so the feature can be
documented properly?

https://www.mercurial-scm.org/wiki/GrepPlan#hg_grep
"If given a set of revisions, it will do the same but search the given
revision(s)."
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D3943: scmutil: rewrite docstring for filecache

[indygreg (Gregory Szorc)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG3b072388ca78: scmutil: rewrite docstring for filecache 
(authored by indygreg, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3943?vs=9588&id=9589

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

AFFECTED FILES
  mercurial/scmutil.py

CHANGE DETAILS

diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -1166,21 +1166,32 @@
 entry.refresh()
 
 class filecache(object):
-'''A property like decorator that tracks files under .hg/ for updates.
+"""A property like decorator that tracks files under .hg/ for updates.
 
-Records stat info when called in _filecache.
+On first access, the files defined as arguments are stat()ed and the
+results cached. The decorated function is called. The results are stashed
+away in a ``_filecache`` dict on the object whose method is decorated.
 
-On subsequent calls, compares old stat info with new info, and recreates 
the
-object when any of the files changes, updating the new stat info in
-_filecache.
+On subsequent access, the cached result is returned.
+
+On external property set operations, stat() calls are performed and the new
+value is cached.
+
+On property delete operations, cached data is removed.
 
-Mercurial either atomic renames or appends for files under .hg,
-so to ensure the cache is reliable we need the filesystem to be able
-to tell us if a file has been replaced. If it can't, we fallback to
-recreating the object on every call (essentially the same behavior as
-propertycache).
+When using the property API, cached data is always returned, if available:
+no stat() is performed to check if the file has changed and if the function
+needs to be called to reflect file changes.
 
-'''
+Others can muck about with the state of the ``_filecache`` dict. e.g. they
+can populate an entry before the property's getter is called. In this case,
+entries in ``_filecache`` will be used during property operations,
+if available. If the underlying file changes, it is up to external callers
+to reflect this by e.g. calling ``delattr(obj, attr)`` to remove the cached
+method result as well as possibly calling ``del obj._filecache[attr]`` to
+remove the ``filecacheentry``.
+"""
+
 def __init__(self, *paths):
 self.paths = paths
 



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

D3932: tests: add test demonstrating phase loss when cloning (issue5939)

[indygreg (Gregory Szorc)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG2a227782e754: tests: add test demonstrating phase loss when 
cloning (issue5939) (authored by indygreg, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3932?vs=9562&id=9590

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

AFFECTED FILES
  tests/test-phases-exchange.t

CHANGE DETAILS

diff --git a/tests/test-phases-exchange.t b/tests/test-phases-exchange.t
--- a/tests/test-phases-exchange.t
+++ b/tests/test-phases-exchange.t
@@ -1,5 +1,6 @@
   $ cat >> $HGRCPATH << EOF
   > [extensions]
+  > drawdag=$TESTDIR/drawdag.py
   > phasereport=$TESTDIR/testlib/ext-phase-report.py
   > EOF
 
@@ -1174,6 +1175,8 @@
   $ hg phase f54f1bb90ff3
   2: draft
 
+  $ killdaemons.py
+
 put the changeset in the draft state again
 (first test after this one expect to be able to copy)
 
@@ -1379,3 +1382,178 @@
   o  9 draft a-G - 3e27b6f1eee1
   |
   ~
+
+Test phases exchange when a phaseroot is on a merge
+
+  $ hg init mergetest
+  $ cd mergetest
+  > cat > .hg/hgrc << EOF
+  > [phases]
+  > publish = false
+  > EOF
+
+  $ hg debugdrawdag << EOF
+  > E Z
+  > |\|
+  > D Y
+  > | |
+  > C X
+  > |/
+  > B
+  > |
+  > A
+  > EOF
+  test-debug-phase: new rev 0:  x -> 1
+  test-debug-phase: new rev 1:  x -> 1
+  test-debug-phase: new rev 2:  x -> 1
+  test-debug-phase: new rev 3:  x -> 1
+  test-debug-phase: new rev 4:  x -> 1
+  test-debug-phase: new rev 5:  x -> 1
+  test-debug-phase: new rev 6:  x -> 1
+  test-debug-phase: new rev 7:  x -> 1
+
+  $ hg phase --public -r D
+  test-debug-phase: move rev 0: 1 -> 0
+  test-debug-phase: move rev 1: 1 -> 0
+  test-debug-phase: move rev 2: 1 -> 0
+  test-debug-phase: move rev 4: 1 -> 0
+
+  $ hg log -G -T '{shortest(node, 5)} {phase}'
+  o  bb947 draft
+  |
+  | o  5ac28 draft
+  |/|
+  o |  13b7b draft
+  | |
+  | o  f5853 public
+  | |
+  o |  c67c4 draft
+  | |
+  | o  26805 public
+  |/
+  o  11247 public
+  |
+  o  426ba public
+  
+  $ cd ..
+
+Works with default settings
+
+  $ hg -R mergetest serve -p $HGPORT -d --pid-file=hg.pid
+  $ cat hg.pid >> $DAEMON_PIDS
+
+  $ hg clone -U http://localhost:$HGPORT mergetest-normal
+  requesting all changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 8 changesets with 7 changes to 7 files (+1 heads)
+  new changesets 426bada5c675:bb94757e651a
+  test-debug-phase: new rev 0:  x -> 0
+  test-debug-phase: new rev 1:  x -> 0
+  test-debug-phase: new rev 2:  x -> 0
+  test-debug-phase: new rev 3:  x -> 1
+  test-debug-phase: new rev 4:  x -> 0
+  test-debug-phase: new rev 5:  x -> 1
+  test-debug-phase: new rev 6:  x -> 1
+  test-debug-phase: new rev 7:  x -> 1
+
+  $ hg -R mergetest-normal log -G -T '{shortest(node, 5)} {phase}'
+  o  bb947 draft
+  |
+  | o  5ac28 draft
+  |/|
+  o |  13b7b draft
+  | |
+  | o  f5853 public
+  | |
+  o |  c67c4 draft
+  | |
+  | o  26805 public
+  |/
+  o  11247 public
+  |
+  o  426ba public
+  
+  $ killdaemons.py
+
+With legacy listkeys over bundle2
+TODO issue 5939: public phase lost on 26805 and f5853
+
+  $ hg -R mergetest --config devel.legacy.exchange=phases serve -p $HGPORT -d 
--pid-file=hg.pid
+  $ cat hg.pid >> $DAEMON_PIDS
+
+  $ hg clone -U http://localhost:$HGPORT mergetest-nobinarypart
+  requesting all changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 8 changesets with 7 changes to 7 files (+1 heads)
+  new changesets 426bada5c675:bb94757e651a
+  test-debug-phase: new rev 0:  x -> 0
+  test-debug-phase: new rev 1:  x -> 0
+  test-debug-phase: new rev 2:  x -> 1
+  test-debug-phase: new rev 3:  x -> 1
+  test-debug-phase: new rev 4:  x -> 1
+  test-debug-phase: new rev 5:  x -> 1
+  test-debug-phase: new rev 6:  x -> 1
+  test-debug-phase: new rev 7:  x -> 1
+
+  $ hg -R mergetest-nobinarypart log -G -T '{shortest(node, 5)} {phase}'
+  o  bb947 draft
+  |
+  | o  5ac28 draft
+  |/|
+  o |  13b7b draft
+  | |
+  | o  f5853 draft
+  | |
+  o |  c67c4 draft
+  | |
+  | o  26805 draft
+  |/
+  o  11247 public
+  |
+  o  426ba public
+  
+  $ killdaemons.py
+
+Without bundle2
+TODO issue 5939: public phase lost on 26805 and f5853
+
+  $ hg -R mergetest serve -p $HGPORT -d --pid-file=hg.pid
+  $ cat hg.pid >> $DAEMON_PIDS
+
+  $ hg --config devel.legacy.exchange=bundle1 clone -U 
http://localhost:$HGPORT mergetest-bundle1
+  requesting all changes
+  adding changesets
+  adding manifests
+  adding file changes
+  added 8 changesets with 7 changes to 7 files (+1 heads)
+  new changesets 426bada5c675:bb94757e651a
+  test-debug-phase: new rev 0:  x -> 0
+  test-debug-phase: new rev 1:  x -> 0
+  test-debug-phase: new rev 2:  x -> 1
+  test-debug-phase: new rev 3:  x -> 1
+  test-debug-phase: new rev 4:  x -> 1
+  test-debug-phase: new rev 5:  x -> 1
+  test-debug-phase: new rev 6:  x -> 1
+  test-debug-phase: new rev 7:  x -> 1
+
+  $ hg -R mergetest-bundle1 log -G -T '{shortest(node, 5

Re: D3919: grep: restore pre-9ef10437bb88 behavior, enable wdir search by tweakdefaults

[Yuya Nishihara]

> So what's the next step should be ?

Maybe add support for "--all-files -rMULTIREV" so the feature can be
documented properly?

https://www.mercurial-scm.org/wiki/GrepPlan#hg_grep
"If given a set of revisions, it will do the same but search the given
revision(s)."
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D3943: scmutil: rewrite docstring for filecache

[indygreg (Gregory Szorc)]

indygreg created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  The old docstring was incorrect in that it said that subsequent
  calls perform a stat() and refresh the object if things change.
  This is not how things work: __get__ populates obj.__dict__[self.sname]
  with the result of the decorated function and returns this value
  without validation on subsequent calls, if available.
  
  The correct usage of this type is kinda wonky. It would probably
  benefit from a refactor. But I don't have time to do that right
  now. But we can change the docstring so others aren't entrapped by
  its lies (like I was when using repofilecache in a Mozilla extension).

REPOSITORY
  rHG Mercurial

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

AFFECTED FILES
  mercurial/scmutil.py

CHANGE DETAILS

diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -1166,21 +1166,32 @@
 entry.refresh()
 
 class filecache(object):
-'''A property like decorator that tracks files under .hg/ for updates.
+"""A property like decorator that tracks files under .hg/ for updates.
 
-Records stat info when called in _filecache.
+On first access, the files defined as arguments are stat()ed and the
+results cached. The decorated function is called. The results are stashed
+away in a ``_filecache`` dict on the object whose method is decorated.
 
-On subsequent calls, compares old stat info with new info, and recreates 
the
-object when any of the files changes, updating the new stat info in
-_filecache.
+On subsequent access, the cached result is returned.
+
+On external property set operations, stat() calls are performed and the new
+value is cached.
+
+On property delete operations, cached data is removed.
 
-Mercurial either atomic renames or appends for files under .hg,
-so to ensure the cache is reliable we need the filesystem to be able
-to tell us if a file has been replaced. If it can't, we fallback to
-recreating the object on every call (essentially the same behavior as
-propertycache).
+When using the property API, cached data is always returned, if available:
+no stat() is performed to check if the file has changed and if the function
+needs to be called to reflect file changes.
 
-'''
+Others can muck about with the state of the ``_filecache`` dict. e.g. they
+can populate an entry before the property's getter is called. In this case,
+entries in ``_filecache`` will be used during property operations,
+if available. If the underlying file changes, it is up to external callers
+to reflect this by e.g. calling ``delattr(obj, attr)`` to remove the cached
+method result as well as possibly calling ``del obj._filecache[attr]`` to
+remove the ``filecacheentry``.
+"""
+
 def __init__(self, *paths):
 self.paths = paths
 



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

Re: D3919: grep: restore pre-9ef10437bb88 behavior, enable wdir search by tweakdefaults

[Sangeet Kumar Mishra]

So what's the next step should be ?

On Fri, 13 Jul 2018, 18:13 yuja (Yuya Nishihara), <
phabrica...@mercurial-scm.org> wrote:

> yuja added a comment.
>
>
>   >   How do you feel about treating the current behavior of `hg grep` as
> a bug?
>
>   I'm 0 on this. 10 years are long enough to turn a bug into a feature, but
>   I agree the grep (without --all/--diff) is useless. If we had no easy way
>   to opt-in BC, I would give thumbs up on changing the default behavior.
>
> REPOSITORY
>   rHG Mercurial
>
> REVISION DETAIL
>   https://phab.mercurial-scm.org/D3919
>
> To: yuja, #hg-reviewers, sangeet259, pulkit
> Cc: durin42, mercurial-devel
> ___
> 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: Discussion about Mercurial 4.8 Sprint

[Augie Fackler]

> On Jul 13, 2018, at 09:29, Martin von Zweigbergk via Mercurial-devel 
>  wrote:
> 
> We took people's voices into account. That's why we choose Europe over Asia 
> (it felt like people on the committee generally preferred Tokyo). But again, 
> I agree that we should have been more transparent.

Yep, sorry about the lack of transparency. I think we all burned out on the 
"all the voices" thread and just decided to decide.

(One other thing that came up, by way of transparency: we'd like to try and 
plan the spring 2019 sprint somewhat soon, with an eye towards pulling off the 
Asia-based sprint we've talked about for something like 3 years. I think it'd 
be nice to get Asia into the rotation, as we might see some new faces.)___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D3871: rebase: improve output of --confirm option

[durin42 (Augie Fackler)]

durin42 added a comment.


  This doesn't apply cleanly, could you rebase it?

INLINE COMMENTS

> rebase.py:975
>  with util.acceptintervention(dsguard):
> -rbsrt._performrebase(tr)
> +rbsrt._performrebase(tr, supprbinfo=supprbinfo)
>  if not leaveunfinished:

I feel like the functions that accept supprbinfo should grow a docstring or 
comment that explains what supprbinfo does.

(I sort of figured it out, but it took a while.)

REPOSITORY
  rHG Mercurial

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

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

Re: Discussion about Mercurial 4.8 Sprint

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 13, 2018, 00:32 Sean Farley  wrote:

>
> Martin von Zweigbergk  writes:
>
> > On Thu, Jul 12, 2018 at 9:11 PM Sean Farley  wrote:
> >
> >>
> >> Martin von Zweigbergk  writes:
> >>
> >> > On Thu, Jul 12, 2018, 17:41 Sean Farley  wrote:
> >> >
> >> >>
> >> >> Martin von Zweigbergk via Mercurial-devel <
> >> >> mercurial-devel@mercurial-scm.org> writes:
> >> >>
> >> >> > Since there was no consensus in this thread, we discussed it in the
> >> >> > steering committee. We decided to do it in Europe this time (i.e.
> the
> >> 4.8
> >> >> > sprint) since everyone indicated that they could make it there. We
> >> also
> >> >> > decided to do it Oct 12-14 and to do it in Stockholm. I'll send a
> >> >> separate
> >> >> > email to the list about that.
> >> >>
> >> >> I guess I'm really confused about this. In this thread, many people,
> >> >> myself included, offered to help and even began the process of
> securing
> >> >> a meeting location.
> >> >>
> >> >> Could you please provide insight on how the decision was made? Were
> >> >> venue offers made privately?
> >> >>
> >> >
> >> > No offers made privately (why do you ask?), the offers we had were on
> the
> >> > wiki. Those offers were Tokyo, Lyon, and Stockholm. According to the
> >> > availability table, everyone was able to come to Europe, but not
> everyone
> >> > could make it to Asia, so we decided not to do it in Tokyo this time.
> The
> >> > Lyon location was an hour or two further away from most locations and
> the
> >> > Stockholm location (except from France, of course). So I proposed
> doing
> >> it
> >> > in Stockholm and no one objected.
> >>
> >> In this thread, we talked and made plans so far for some place in France
> >> (either Paris or Lyon). The wiki page you mentioned is an opt-in only
> >> notification and I haven't edited that page nor was I subscribed which
> >> is why I asked about private offers. Not everyone on this mailing list
> >> got those notifications... so, of course, no one objected because not
> >> many of us even knew Stockholm was a serious contender.
> >>
> >
> > I updated this thread saying that we'd updated wiki with availability for
> > Tokyo and Stockholm. There wasn't much more than a mention of Lyon and
> > Paris either, so I don't know why Stockholm would be less serious.
> >
> >
> >> It feels like a decision was made without involving the rest of the
> >> community that was already discussing this sprint.
> >>
> >
> > I can understand that it felt that way, and I'm sorry about that. I
> suppose
> > we could have decided only between Asia and Europe to start with and then
> > updated the Availability table on the wiki to have Lyon/Stockholm columns
> > instead (Paris didn't seem realistic given the small space). That would
> > clearly have delayed the decision (by a week? two?), but perhaps that
> would
> > have been fine given that the sprint ended up being quite late in the
> fall
> > this time. At least I (I don't know about others) felt like it was better
> > to decide something than to hear everyone's point of view, because I had
> a
> > feeling we would not reach consensus even if we did.
>
> I understand the need to make a decision. But this was making a decision
> without presenting a clear timeline nor even presenting, you know, an
> email saying what you just said above: that you're about to make a
> decision and here are your current thoughts.
>

I agree, that would have been fair. We should have sent a notification to
this thread with something like "This thread is not making progress, so the
steering committee will decide on a location and time". That message should
also have been clear that we were going to decide on an exact location, not
just a continent, so people could provide more specific comments about
that. I don't think we'd heard anything more specific than "I prefer
Europe" or "I prefer Asia" in this thread (or on the wiki), except that it
was pretty clear that Kyle preferred Tokyo (or at least Japan in general).
Thanks for the feedback. We'll try to do better next time.


> > Let's try to start planning next sprint earlier (soon), so this doesn't
> > happen again.
>
> This is side stepping the issue. After this experience, why would anyone
> think their voice would be heard? Remember, it was people on the
> committee that asked for more people to help out and voice their
> thoughts.
>

We took people's voices into account. That's why we choose Europe over Asia
(it felt like people on the committee generally preferred Tokyo). But
again, I agree that we should have been more transparent.


> Yes, I agree that planning needs to start earlier.
>
> > By the way, you haven't added your name to the wiki. Will we see you
> there?
>
> I haven't decided yet.
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2] config: introduce load order tracking

[Yuya Nishihara]

On Fri, 13 Jul 2018 10:30:33 +0200, Boris FELD wrote:
> On 11/07/2018 13:32, David Demelier wrote:
> > On Wed, 2018-07-11 at 00:01 +0900, Yuya Nishihara wrote:
> >> If the problem to be addressed by this hack is important, and if the
> >> hack is
> >> really simple, sure I would say go for it. But I, as an old Mercurial
> >> user,
> >> see the bulk renaming of the config keys is minor improvement.
> > I think it's important, consistency in a software shows a strong core
> > guideline applied and strict reviewing. The current hgrc manual shows
> > three different styles along with unreadable names like
> > backgroundclosethreadcount.
> 
> We agree with David here that consistency helps the user experience.

I know. I'm just saying it isn't an immediate problem enough to add a
one-off hack to the config system.

> Even for more experienced contributors, configuration inconsistency
> leads to waste time at multiple occurrences on mistakes. This happens on
> a regular basis at octobus or at places we provide support to.

For that purpose, I think it's better to add a linter (e.g. hg config --check)
to detect unknown (but similar to registered) names. Inserting dashes to every
config name is merely a partial solution for ambiguous naming. There's always
inconsistency such as "X-count" vs "Xs" for the number of X.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D3919: grep: restore pre-9ef10437bb88 behavior, enable wdir search by tweakdefaults

[yuja (Yuya Nishihara)]

yuja added a comment.


  >   How do you feel about treating the current behavior of `hg grep` as a bug?
  
  I'm 0 on this. 10 years are long enough to turn a bug into a feature, but
  I agree the grep (without --all/--diff) is useless. If we had no easy way
  to opt-in BC, I would give thumbs up on changing the default behavior.

REPOSITORY
  rHG Mercurial

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

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

Re: D3919: grep: restore pre-9ef10437bb88 behavior, enable wdir search by tweakdefaults

[Yuya Nishihara]

>   How do you feel about treating the current behavior of `hg grep` as a bug?

I'm 0 on this. 10 years are long enough to turn a bug into a feature, but
I agree the grep (without --all/--diff) is useless. If we had no easy way
to opt-in BC, I would give thumbs up on changing the default behavior.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: D3870: rebase: add --confirm option

[Yuya Nishihara]

>   >> +if confirm:
>   >>  +# abort as in-memory merge doesn't support conflict
>   >>  +rbsrt._prepareabortorcontinue(isabort=True, 
> backup=False,
>   >>  +  suppwarns=True)
>   >>  +needsabort = False
>   >>  +if not ui.promptchoice(_(b'apply changes (yn)?'
>   >>  + b'$$ &Yes $$ &No')):
>   > 
>   > Nit: This isn't actually "apply changes".
>   
>   Hmm, then what it should be?

I think we'll need to tell that we'll rerun the rebase that's known to have
at least one merge conflict. "apply changes" sounds like it would just
finalize the rebase up to the previous revision of the merge conflict.

Alternatively, it can just abort without the prompt since the dry-run was
incomplete.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D3870: rebase: add --confirm option

[yuja (Yuya Nishihara)]

yuja added a comment.


  >   >> +if confirm:
  >   >>  +# abort as in-memory merge doesn't support conflict
  >   >>  +rbsrt._prepareabortorcontinue(isabort=True, 
backup=False,
  >   >>  +  suppwarns=True)
  >   >>  +needsabort = False
  >   >>  +if not ui.promptchoice(_(b'apply changes (yn)?'
  >   >>  + b'$$ &Yes $$ &No')):
  >   > 
  >   > Nit: This isn't actually "apply changes".
  >   
  >   Hmm, then what it should be?
  
  I think we'll need to tell that we'll rerun the rebase that's known to have
  at least one merge conflict. "apply changes" sounds like it would just
  finalize the rebase up to the previous revision of the merge conflict.
  
  Alternatively, it can just abort without the prompt since the dry-run was
  incomplete.

REPOSITORY
  rHG Mercurial

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

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

D3934: revlog: delete isdescendantrev() in favor of isancestorrev()

[martinvonz (Martin von Zweigbergk)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG21846c94e605: revlog: delete isdescendantrev() in favor of 
isancestorrev() (authored by martinvonz, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3934?vs=9570&id=9580

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

AFFECTED FILES
  mercurial/context.py
  mercurial/revlog.py

CHANGE DETAILS

diff --git a/mercurial/revlog.py b/mercurial/revlog.py
--- a/mercurial/revlog.py
+++ b/mercurial/revlog.py
@@ -1645,21 +1645,6 @@
 c.append(self.node(r))
 return c
 
-def isdescendantrev(self, a, b):
-"""True if revision a is a descendant of revision b
-
-A revision is considered a descendant of itself.
-
-The implementation of this is trivial but the use of
-commonancestorsheads is not."""
-if b == nullrev:
-return True
-elif a == b:
-return True
-elif a < b:
-return False
-return b in self._commonancestorsheads(a, b)
-
 def commonancestorsheads(self, a, b):
 """calculate all the heads of the common ancestors of nodes a and b"""
 a, b = self.rev(a), self.rev(b)
@@ -1684,8 +1669,17 @@
 def isancestorrev(self, a, b):
 """return True if revision a is an ancestor of revision b
 
-A revision is considered an ancestor of itself."""
-return self.isdescendantrev(b, a)
+A revision is considered an ancestor of itself.
+
+The implementation of this is trivial but the use of
+commonancestorsheads is not."""
+if a == nullrev:
+return True
+elif a == b:
+return True
+elif a > b:
+return False
+return a in self._commonancestorsheads(a, b)
 
 def ancestor(self, a, b):
 """calculate the "best" common ancestor of nodes a and b"""
diff --git a/mercurial/context.py b/mercurial/context.py
--- a/mercurial/context.py
+++ b/mercurial/context.py
@@ -591,7 +591,7 @@
 
 def descendant(self, other):
 """True if other is descendant of this changeset"""
-return self._repo.changelog.isdescendantrev(other._rev, self._rev)
+return self._repo.changelog.isancestorrev(self._rev, other._rev)
 
 def walk(self, match):
 '''Generates matching file names.'''



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

D3936: context: rename descendant() to isancestorof()

[martinvonz (Martin von Zweigbergk)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHGfbec9c0b32d3: context: rename descendant() to 
isancestorof() (authored by martinvonz, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3936?vs=9572&id=9582

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

AFFECTED FILES
  mercurial/bookmarks.py
  mercurial/context.py
  mercurial/copies.py

CHANGE DETAILS

diff --git a/mercurial/copies.py b/mercurial/copies.py
--- a/mercurial/copies.py
+++ b/mercurial/copies.py
@@ -416,14 +416,14 @@
 # common ancestor or not without explicitly checking it, it's better to
 # determine that here.
 #
-# base.descendant(wc) is False, work around that
+# base.isancestorof(wc) is False, work around that
 _c1 = c1.p1() if c1.rev() is None else c1
 _c2 = c2.p1() if c2.rev() is None else c2
 # an endpoint is "dirty" if it isn't a descendant of the merge base
 # if we have a dirty endpoint, we need to trigger graft logic, and also
 # keep track of which endpoint is dirty
-dirtyc1 = not base.descendant(_c1)
-dirtyc2 = not base.descendant(_c2)
+dirtyc1 = not base.isancestorof(_c1)
+dirtyc2 = not base.isancestorof(_c2)
 graft = dirtyc1 or dirtyc2
 tca = base
 if graft:
diff --git a/mercurial/context.py b/mercurial/context.py
--- a/mercurial/context.py
+++ b/mercurial/context.py
@@ -589,8 +589,8 @@
 short(n) for n in sorted(cahs) if n != anc))
 return changectx(self._repo, anc)
 
-def descendant(self, other):
-"""True if other is descendant of this changeset"""
+def isancestorof(self, other):
+"""True if this changeset is an ancestor of other"""
 return self._repo.changelog.isancestorrev(self._rev, other._rev)
 
 def walk(self, match):
diff --git a/mercurial/bookmarks.py b/mercurial/bookmarks.py
--- a/mercurial/bookmarks.py
+++ b/mercurial/bookmarks.py
@@ -813,7 +813,7 @@
 return new.node() in obsutil.foreground(repo, [old.node()])
 else:
 # still an independent clause as it is lazier (and therefore faster)
-return old.descendant(new)
+return old.isancestorof(new)
 
 def checkformat(repo, mark):
 """return a valid version of a potential bookmark name



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

D3940: rebase: reduce scope of a variable

[martinvonz (Martin von Zweigbergk)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG99ed6e2f6606: rebase: reduce scope of a variable (authored 
by martinvonz, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3940?vs=9577&id=9583

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

AFFECTED FILES
  hgext/rebase.py

CHANGE DETAILS

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1858,7 +1858,6 @@
 extinctnodes = set(cl.node(r) for r in repo.revs('extinct()'))
 for srcrev in rebaseobsrevs:
 srcnode = cl.node(srcrev)
-destnode = cl.node(destmap[srcrev])
 # XXX: more advanced APIs are required to handle split correctly
 successors = set(obsutil.allsuccessors(repo.obsstore, [srcnode]))
 # obsutil.allsuccessors includes node itself
@@ -1870,6 +1869,7 @@
 # no successor
 obsoletenotrebased[srcrev] = None
 else:
+destnode = cl.node(destmap[srcrev])
 for succnode in successors:
 if succnode not in nodemap:
 continue



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

D3939: rebase: correct misleading message in --confirm option

[khanchi97 (Sushil khanchi)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG35b3f686157a: rebase: correct misleading message in 
--confirm option (authored by khanchi97, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3939?vs=9575&id=9587

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

AFFECTED FILES
  hgext/rebase.py
  tests/test-rebase-inmemory.t

CHANGE DETAILS

diff --git a/tests/test-rebase-inmemory.t b/tests/test-rebase-inmemory.t
--- a/tests/test-rebase-inmemory.t
+++ b/tests/test-rebase-inmemory.t
@@ -369,7 +369,7 @@
   $ hg rebase -s 2 -d . --keep --config ui.interactive=True --confirm << EOF
   > n
   > EOF
-  starting rebase...
+  starting in-memory rebase
   rebasing 2:177f92b77385 "c"
   rebasing 3:055a42cdd887 "d"
   rebasing 4:e860deea161a "e"
@@ -400,7 +400,7 @@
   $ hg rebase -s 2 -d . --keep --config ui.interactive=True --confirm << EOF
   > y
   > EOF
-  starting rebase...
+  starting in-memory rebase
   rebasing 2:177f92b77385 "c"
   rebasing 3:055a42cdd887 "d"
   rebasing 4:e860deea161a "e"
@@ -475,7 +475,7 @@
   $ hg rebase -s 4 -d . --keep --config ui.interactive=True --confirm << EOF
   > n
   > EOF
-  starting rebase...
+  starting in-memory rebase
   rebasing 4:e860deea161a "e"
   merging e
   hit a merge conflict
@@ -516,7 +516,7 @@
   $ hg rebase -s 4 -d . --keep --config ui.interactive=True --confirm << EOF
   > y
   > EOF
-  starting rebase...
+  starting in-memory rebase
   rebasing 4:e860deea161a "e"
   merging e
   hit a merge conflict
diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -854,7 +854,7 @@
 rbsrt = rebaseruntime(repo, ui, inmemory=True, opts=opts)
 confirm = opts.get('confirm')
 if confirm:
-ui.status(_('starting rebase...\n'))
+ui.status(_('starting in-memory rebase\n'))
 else:
 ui.status(_('starting dry-run rebase; repository will not be '
 'changed\n'))



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

D3938: rebase: make sure we don't loose the return code in --confirm option

[khanchi97 (Sushil khanchi)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHGa50482254b0a: rebase: make sure we don't loose the 
return code in --confirm option (authored by khanchi97, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3938?vs=9574&id=9586

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

AFFECTED FILES
  hgext/rebase.py

CHANGE DETAILS

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -874,7 +874,7 @@
 needsabort = False
 if not ui.promptchoice(_(b'apply changes (yn)?'
  b'$$ &Yes $$ &No')):
-_dorebase(ui, repo, opts, inmemory=False)
+return _dorebase(ui, repo, opts, inmemory=False)
 return 1
 else:
 if confirm:



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

D3941: rebase: avoid converting from nodes to revnums twice

[martinvonz (Martin von Zweigbergk)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG0f8599afb92f: rebase: avoid converting from nodes to 
revnums twice (authored by martinvonz, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3941?vs=9578&id=9584

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

AFFECTED FILES
  hgext/rebase.py

CHANGE DETAILS

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1869,19 +1869,17 @@
 # no successor
 obsoletenotrebased[srcrev] = None
 else:
-destnode = cl.node(destmap[srcrev])
-for succnode in successors:
-if succnode not in nodemap:
-continue
-if cl.isancestor(succnode, destnode):
-obsoletenotrebased[srcrev] = nodemap[succnode]
+dstrev = destmap[srcrev]
+succrevs = [nodemap[s] for s in successors if s in nodemap]
+for succrev in succrevs:
+if cl.isancestorrev(succrev, dstrev):
+obsoletenotrebased[srcrev] = succrev
 break
 else:
 # If 'srcrev' has a successor in rebase set but none in
 # destination (which would be catched above), we shall skip it
 # and its descendants to avoid divergence.
-if any(nodemap[s] in destmap for s in successors
-   if s in nodemap):
+if any(s in destmap for s in succrevs):
 obsoletewithoutsuccessorindestination.add(srcrev)
 
 return (



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

D3942: rebase: use revnums (not nodes) for set of extinct revisions

[martinvonz (Martin von Zweigbergk)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHG20a30bb8f276: rebase: use revnums (not nodes) for set of 
extinct revisions (authored by martinvonz, committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3942?vs=9579&id=9585

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

AFFECTED FILES
  hgext/rebase.py

CHANGE DETAILS

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -1855,22 +1855,22 @@
 assert repo.filtername is None
 cl = repo.changelog
 nodemap = cl.nodemap
-extinctnodes = set(cl.node(r) for r in repo.revs('extinct()'))
+extinctrevs = set(repo.revs('extinct()'))
 for srcrev in rebaseobsrevs:
 srcnode = cl.node(srcrev)
 # XXX: more advanced APIs are required to handle split correctly
 successors = set(obsutil.allsuccessors(repo.obsstore, [srcnode]))
 # obsutil.allsuccessors includes node itself
 successors.remove(srcnode)
-if successors.issubset(extinctnodes):
+succrevs = {nodemap[s] for s in successors if s in nodemap}
+if succrevs.issubset(extinctrevs):
 # all successors are extinct
 obsoleteextinctsuccessors.add(srcrev)
 if not successors:
 # no successor
 obsoletenotrebased[srcrev] = None
 else:
 dstrev = destmap[srcrev]
-succrevs = [nodemap[s] for s in successors if s in nodemap]
 for succrev in succrevs:
 if cl.isancestorrev(succrev, dstrev):
 obsoletenotrebased[srcrev] = succrev



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

D3935: copies: delete now-unnecessary check for "a == b" before "a.descendant(b)"

[martinvonz (Martin von Zweigbergk)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rHGb5891bf8ab13: copies: delete now-unnecessary check for 
"a == b" before "a.descendant(b)" (authored by martinvonz, 
committed by ).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D3935?vs=9571&id=9581

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

AFFECTED FILES
  mercurial/copies.py

CHANGE DETAILS

diff --git a/mercurial/copies.py b/mercurial/copies.py
--- a/mercurial/copies.py
+++ b/mercurial/copies.py
@@ -416,14 +416,14 @@
 # common ancestor or not without explicitly checking it, it's better to
 # determine that here.
 #
-# base.descendant(wc) and base.descendant(base) are False, work around that
+# base.descendant(wc) is False, work around that
 _c1 = c1.p1() if c1.rev() is None else c1
 _c2 = c2.p1() if c2.rev() is None else c2
 # an endpoint is "dirty" if it isn't a descendant of the merge base
 # if we have a dirty endpoint, we need to trigger graft logic, and also
 # keep track of which endpoint is dirty
-dirtyc1 = not (base == _c1 or base.descendant(_c1))
-dirtyc2 = not (base == _c2 or base.descendant(_c2))
+dirtyc1 = not base.descendant(_c1)
+dirtyc2 = not base.descendant(_c2)
 graft = dirtyc1 or dirtyc2
 tca = base
 if graft:



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

D3919: grep: restore pre-9ef10437bb88 behavior, enable wdir search by tweakdefaults

[durin42 (Augie Fackler)]

durin42 added a comment.


  >   If we can take the current `hg grep` behavior as a bug, we can say the
  >   same thing for python-hglib. I don't want to make hglib grep diverged from
  >   hg one since hglib is a thin wrapper.
  
  That's not a bad thought. Sounds like a plan to me.
  
  How do you feel about treating the current behavior of `hg grep` as a bug?

REPOSITORY
  rHG Mercurial

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

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

Re: [PATCH 01 of 13] sparse-read: target density of 50% instead of 25%

[Boris FELD]

On 11/07/2018 00:37, Gregory Szorc wrote:
On Tue, Jul 10, 2018 at 6:27 AM, Boris Feld > wrote:


# HG changeset patch
# User Paul Morelle mailto:paul.more...@octobus.net>>
# Date 1529680344 -7200
#      Fri Jun 22 17:12:24 2018 +0200
# Node ID c24db8e9c40d26bd106954c7186d1ff30dad6c19
# Parent  9b077e5fa8ba8d89568d07a4815685d5db4147fe
# EXP-Topic write-for-sparse-read
# Available At https://bitbucket.org/octobus/mercurial-devel/

#              hg pull
https://bitbucket.org/octobus/mercurial-devel/
 -r c24db8e9c40d
sparse-read: target density of 50% instead of 25%


I queued this series.

One of the patches introduced a double space after a "<". I cleaned 
this up in flight.


I'm not super keen on introducing the test revlog class and the inline 
doctests. test-revlog.py might be a better home for those tests. But I 
don't want to block landing on that.
I'm not a fan of mixing test class and actual code either. However, I 
think the tests are more readable as doctest. Maybe we should have some 
`mercurial.doctestutil` module or something similar for the test class?


Since you are experimenting with revlog reading strategies, if you 
have time, it would be interesting to see if memory mapping the revlog 
has any performance benefits. Obviously that will increase memory 
requirements. The OS will reserve memory for the size of the mmap 
segment. But it shouldn't actually be allocated until the underlying 
bytes are accessed. I'd like to think that on machines with gigabytes 
of memory, this would "just work" and would be no worse than our 
current strategy where we read a bunch of chunks in memory. If Python 
properly supports 0-copy on reads from a mmap() segment and we can 
throw away the mmap after resolving a revision, I'd expect to see a 
performance improvement because I/O is handled by the memory system 
and not Python. But we won't know until we measure it!


That's an interesting idea, we are adding it to our list of potential 
improvements. mmap can have tricky side-effects so it will need careful 
investigation. Using mmap seems to give good results for indexes, so it 
could help for data too.


We have already some done and reflections started on several potential 
improvements, so we will focus on these experiments first. Here is a 
roughly sorted list of what we want to look at and experiment around revlog:


* writing "sparse-revlog" to work around pathological case around 
chain-span limitation (currently in testing/benchmark)

  (this replace experimental.maxdeltachainspan)

* Chain length improvement
  (improving snapshot reuse, intermediate, snapshots, etc)

* mmapindex enabled by default,

* zstd as compression for storage,

* mmap for reading delta (your proposal).

Unfortunately, validating each of these experiment takes time, for 
converting + writing code + running benchmarks + ... We are about 1 or 2 
weeks minimum per experiment, so progress will be slow paced.


Cheers,

--
Boris Feld



The target density value is wrong. The default target chain span is
4*text-length. However, the target max chain payload is
2*text-length. So
default target density should be 50% (2/4) not 25% (1/4).

diff --git a/mercurial/configitems.py b/mercurial/configitems.py
--- a/mercurial/configitems.py
+++ b/mercurial/configitems.py
@@ -594,7 +594,7 @@ coreconfigitem('experimental', 'sparse-r
     default=False,
 )
 coreconfigitem('experimental', 'sparse-read.density-threshold',
-    default=0.25,
+    default=0.50,
 )
 coreconfigitem('experimental', 'sparse-read.min-gap-size',
     default='256K',
diff --git a/mercurial/revlog.py b/mercurial/revlog.py
--- a/mercurial/revlog.py
+++ b/mercurial/revlog.py
@@ -625,7 +625,7 @@ class revlog(object):
         self._compengine = 'zlib'
         self._maxdeltachainspan = -1
         self._withsparseread = False
-        self._srdensitythreshold = 0.25
+        self._srdensitythreshold = 0.50
         self._srmingapsize = 262144

         mmapindexthreshold = None




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

Re: [PATCH 1 of 2] config: introduce load order tracking

[Boris FELD]

On 11/07/2018 13:32, David Demelier wrote:

On Wed, 2018-07-11 at 00:01 +0900, Yuya Nishihara wrote:

If the problem to be addressed by this hack is important, and if the
hack is
really simple, sure I would say go for it. But I, as an old Mercurial
user,
see the bulk renaming of the config keys is minor improvement.

I think it's important, consistency in a software shows a strong core
guideline applied and strict reviewing. The current hgrc manual shows
three different styles along with unreadable names like
backgroundclosethreadcount.


We agree with David here that consistency helps the user experience.

Even for more experienced contributors, configuration inconsistency 
leads to waste time at multiple occurrences on mistakes. This happens on 
a regular basis at octobus or at places we provide support to.


We would like to improve the situation in order to improve Mercurial 
contributors and users productivity by avoiding configuration mistakes.




Obviously my opinion is largely biased since I'm half author of the
ConfigConsolidationPlan [0].

What bothers me is that we agreed on a new syntax for new option style
[1] and it's still not applied, see server.streamunbundle and D3893.
However I think you're aware since you personally pushed my deprecated
topic.

Hopefully av6 helps me with it's reviewing :-)

[0]: https://www.mercurial-scm.org/wiki/ConfigConsolidationPlan
[1]: https://www.mercurial-scm.org/wiki/UIGuideline#adding_new_options

Regards,



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

Re: Discussion about Mercurial 4.8 Sprint

[Sean Farley]

Martin von Zweigbergk  writes:

> On Thu, Jul 12, 2018 at 9:11 PM Sean Farley  wrote:
>
>>
>> Martin von Zweigbergk  writes:
>>
>> > On Thu, Jul 12, 2018, 17:41 Sean Farley  wrote:
>> >
>> >>
>> >> Martin von Zweigbergk via Mercurial-devel <
>> >> mercurial-devel@mercurial-scm.org> writes:
>> >>
>> >> > Since there was no consensus in this thread, we discussed it in the
>> >> > steering committee. We decided to do it in Europe this time (i.e. the
>> 4.8
>> >> > sprint) since everyone indicated that they could make it there. We
>> also
>> >> > decided to do it Oct 12-14 and to do it in Stockholm. I'll send a
>> >> separate
>> >> > email to the list about that.
>> >>
>> >> I guess I'm really confused about this. In this thread, many people,
>> >> myself included, offered to help and even began the process of securing
>> >> a meeting location.
>> >>
>> >> Could you please provide insight on how the decision was made? Were
>> >> venue offers made privately?
>> >>
>> >
>> > No offers made privately (why do you ask?), the offers we had were on the
>> > wiki. Those offers were Tokyo, Lyon, and Stockholm. According to the
>> > availability table, everyone was able to come to Europe, but not everyone
>> > could make it to Asia, so we decided not to do it in Tokyo this time. The
>> > Lyon location was an hour or two further away from most locations and the
>> > Stockholm location (except from France, of course). So I proposed doing
>> it
>> > in Stockholm and no one objected.
>>
>> In this thread, we talked and made plans so far for some place in France
>> (either Paris or Lyon). The wiki page you mentioned is an opt-in only
>> notification and I haven't edited that page nor was I subscribed which
>> is why I asked about private offers. Not everyone on this mailing list
>> got those notifications... so, of course, no one objected because not
>> many of us even knew Stockholm was a serious contender.
>>
>
> I updated this thread saying that we'd updated wiki with availability for
> Tokyo and Stockholm. There wasn't much more than a mention of Lyon and
> Paris either, so I don't know why Stockholm would be less serious.
>
>
>> It feels like a decision was made without involving the rest of the
>> community that was already discussing this sprint.
>>
>
> I can understand that it felt that way, and I'm sorry about that. I suppose
> we could have decided only between Asia and Europe to start with and then
> updated the Availability table on the wiki to have Lyon/Stockholm columns
> instead (Paris didn't seem realistic given the small space). That would
> clearly have delayed the decision (by a week? two?), but perhaps that would
> have been fine given that the sprint ended up being quite late in the fall
> this time. At least I (I don't know about others) felt like it was better
> to decide something than to hear everyone's point of view, because I had a
> feeling we would not reach consensus even if we did.

I understand the need to make a decision. But this was making a decision
without presenting a clear timeline nor even presenting, you know, an
email saying what you just said above: that you're about to make a
decision and here are your current thoughts.

> Let's try to start planning next sprint earlier (soon), so this doesn't
> happen again.

This is side stepping the issue. After this experience, why would anyone
think their voice would be heard? Remember, it was people on the
committee that asked for more people to help out and voice their
thoughts.

Yes, I agree that planning needs to start earlier.

> By the way, you haven't added your name to the wiki. Will we see you there?

I haven't decided yet.


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