Re: [PATCH 5 of 6 V2] amend: use scmutil.cleanupnodes (BC)

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-07-07 22:45:19 -0700:
> Okay if I change this (back) from ctx.node() to just node? That seems
> both simpler and clearer (given the "if node" guard).

Good catch! Yes, changing to "node" is cleaner.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 6 V2] amend: use scmutil.cleanupnodes (BC)

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 7:11 PM, Jun Wu  wrote:
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -2891,30 +2889,8 @@ def amend(ui, repo, commitfunc, old, ext
>  # Reroute the working copy parent to the new changeset
>  repo.setparents(newid, nullid)
> -
> -# Move bookmarks from old parent to amend commit
> -bms = repo.nodebookmarks(old.node())
> -if bms:
> -marks = repo._bookmarks
> -for bm in bms:
> -ui.debug('moving bookmarks %r from %s to %s\n' %
> - (marks, old.hex(), hex(newid)))
> -marks[bm] = newid
> -marks.recordchange(tr)
> -#commit the whole amend process
> -if createmarkers:
> -# mark the new changeset as successor of the rewritten 
> one
> -new = repo[newid]
> -obs = [(old, (new,))]
> -if node:
> -obs.append((ctx, ()))
> -
> -obsolete.createmarkers(repo, obs, operation='amend')
> -if not createmarkers and newid != old.node():
> -# Strip the intermediate commit (if there was one) and the 
> amended
> -# commit
> -if node:
> -ui.note(_('stripping intermediate changeset %s\n') % ctx)
> -ui.note(_('stripping amended changeset %s\n') % old)
> -repair.strip(ui, repo, old.node(), topic='amend-backup')
> +mapping = {old.node(): (newid,)}
> +if node:
> +mapping[ctx.node()] = ()

Okay if I change this (back) from ctx.node() to just node? That seems
both simpler and clearer (given the "if node" guard).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 6 V2] rebase: use scmutil.cleanupnodes (issue5606) (BC)

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 7:11 PM, Jun Wu  wrote:
> diff --git a/hgext/rebase.py b/hgext/rebase.py
> --- a/hgext/rebase.py
> +++ b/hgext/rebase.py
> @@ -1326,6 +1293,7 @@ def clearrebased(ui, repo, state, skippe
>  If `collapsedas` is not None, the rebase was a collapse whose result if 
> the
>  `collapsedas` node."""
> -if obsolete.isenabled(repo, obsolete.createmarkersopt):
> -markers = []
> +tonode = repo.changelog.node
> +mapping = {}
> +if True:
>  for rev, newrev in sorted(state.items()):

Nit: The "sorted()" can probably be dropped now. I'm guessing it was
there in order for obsmarkers to be created in deterministic order. I
hope cleanupnodes() takes care of making it deterministic now.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 6 V2] rebase: use scmutil.cleanupnodes (issue5606) (BC)

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-07-07 22:28:05 -0700:
> The line after reads "Note the above graph is wrong since C got
> stripped incorrectly.". I'll remove that line in flight.

Thanks! I fixed it in the multidest branch but forgot this one.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 6 V2] rebase: use scmutil.cleanupnodes (issue5606) (BC)

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 7:11 PM, Jun Wu  wrote:
> diff --git a/tests/test-rebase-conflicts.t b/tests/test-rebase-conflicts.t
> --- a/tests/test-rebase-conflicts.t
> +++ b/tests/test-rebase-conflicts.t
> @@ -401,14 +401,19 @@ Test rebase with obsstore turned on and
>not rebasing ignored 2:26805aba1e60 "C" (C)
>rebasing 3:f585351a92f8 "D" (D)
> -  saved backup bundle to 
> $TESTTMP/b/.hg/strip-backup/f585351a92f8-cb2a9b47-backup.hg (glob)
> +  warning: orphaned descendants detected, not stripping 112478962961
> +  saved backup bundle to 
> $TESTTMP/b/.hg/strip-backup/f585351a92f8-e536a9e4-rebase.hg (glob)
>
>$ rm .hg/localtags
>$ hg tglog
> -  o  3:draft 'D'
> +  o  5:draft 'D'
> +  |
> +  o  4:draft 'B'
>|
> -  o  2:draft 'B'
> +  @  3:draft 'E'
>|
> -  @  1:draft 'E'
> -  |
> +  | o  2:draft 'C'
> +  | |
> +  | o  1:draft 'B'
> +  |/
>o  0:draft 'A'
>

The line after reads "Note the above graph is wrong since C got
stripped incorrectly.". I'll remove that line in flight.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 6 V2] scmutil: make cleanupnodes handle filtered node

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-07-07 21:41:05 -0700:
> Did you mean to use your new drawdag syntax (comments) to create this
> obsmarker? Just checking; I'm fine with it as is.

Good catch. The test could be simplified a bit using the new syntax.

Drawdag change was intended to be used in multi-dest rebase series and I
forgot it could be used here too.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 6 V2] scmutil: make cleanupnodes handle filtered node

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 7:11 PM, Jun Wu  wrote:
> diff --git a/tests/test-obsolete-divergent.t b/tests/test-obsolete-divergent.t
> --- a/tests/test-obsolete-divergent.t
> +++ b/tests/test-obsolete-divergent.t
> @@ -618,2 +620,47 @@ successors-set. (report [A,B] not [A] +
>
>$ cd ..
> +
> +Use scmutil.cleanupnodes API to create divergence
> +
> +  $ hg init cleanupnodes
> +  $ cd cleanupnodes
> +  $ hg debugdrawdag <<'EOS'
> +  >   B1  B3 B4
> +  >   | \|
> +  >   A  Z
> +  > EOS
> +
> +  $ hg update -q B1
> +  $ echo 3 >> B
> +  $ hg commit --amend -m B2

Did you mean to use your new drawdag syntax (comments) to create this
obsmarker? Just checking; I'm fine with it as is.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH V2] revset: make repo.anyrevs accept customized alias override (API)

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1498343382 25200
#  Sat Jun 24 15:29:42 2017 -0700
# Node ID 3a01f8dc2cc144c979134840d6148946fb6f1a0f
# Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 3a01f8dc2cc1
revset: make repo.anyrevs accept customized alias override (API)

Previously repo.anyrevs only expand aliases in [revsetalias] config. This
patch makes it more flexible to accept a customized dict defining aliases
without having to couple with ui.

revsetlang.expandaliases now has the signature (tree, aliases, warn=None)
which is more consistent with templater.expandaliases. revsetlang.py is now
free from "ui", which seems to be a good thing.

diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
--- a/mercurial/debugcommands.py
+++ b/mercurial/debugcommands.py
@@ -1961,7 +1961,9 @@ def debugrevspec(ui, repo, expr, **opts)
 """
 opts = pycompat.byteskwargs(opts)
+aliases = ui.configitems('revsetalias')
 stages = [
 ('parsed', lambda tree: tree),
-('expanded', lambda tree: revsetlang.expandaliases(ui, tree)),
+('expanded', lambda tree: revsetlang.expandaliases(tree, aliases,
+   ui.warn)),
 ('concatenated', revsetlang.foldconcat),
 ('analyzed', revsetlang.analyze),
diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -649,14 +649,17 @@ class localrepository(object):
 yield self[r]
 
-def anyrevs(self, specs, user=False):
+def anyrevs(self, specs, user=False, localalias=None):
 '''Find revisions matching one of the given revsets.
 
 Revset aliases from the configuration are not expanded by default. To
-expand user aliases, specify ``user=True``.
+expand user aliases, specify ``user=True``. To provide some local
+definitions overriding user aliases, set ``localalias`` to
+``{name: definitionstring}``.
 '''
 if user:
-m = revset.matchany(self.ui, specs, repo=self)
+m = revset.matchany(self.ui, specs, repo=self,
+localalias=localalias)
 else:
-m = revset.matchany(None, specs)
+m = revset.matchany(None, specs, localalias=localalias)
 return m(self)
 
diff --git a/mercurial/revset.py b/mercurial/revset.py
--- a/mercurial/revset.py
+++ b/mercurial/revset.py
@@ -2002,5 +2002,5 @@ def match(ui, spec, repo=None, order=def
 return matchany(ui, [spec], repo=repo, order=order)
 
-def matchany(ui, specs, repo=None, order=defineorder):
+def matchany(ui, specs, repo=None, order=defineorder, localalias=None):
 """Create a matcher that will include any revisions matching one of the
 given specs
@@ -2008,4 +2008,7 @@ def matchany(ui, specs, repo=None, order
 If order=followorder, a matcher takes the ordering specified by the input
 set.
+
+If localalias is not None, it is a dict {name: definitionstring}. It takes
+precedence over [revsetalias] config section.
 """
 if not specs:
@@ -2024,6 +2027,13 @@ def matchany(ui, specs, repo=None, order
 ('list',) + tuple(revsetlang.parse(s, lookup) for s in specs))
 
+aliases = []
+warn = None
 if ui:
-tree = revsetlang.expandaliases(ui, tree)
+aliases.extend(ui.configitems('revsetalias'))
+warn = ui.warn
+if localalias:
+aliases.extend(localalias.items())
+if aliases:
+tree = revsetlang.expandaliases(tree, aliases, warn=warn)
 tree = revsetlang.foldconcat(tree)
 tree = revsetlang.analyze(tree, order)
diff --git a/mercurial/revsetlang.py b/mercurial/revsetlang.py
--- a/mercurial/revsetlang.py
+++ b/mercurial/revsetlang.py
@@ -562,12 +562,14 @@ class _aliasrules(parser.basealiasrules)
 return tree[1][1], getlist(tree[2])
 
-def expandaliases(ui, tree):
-aliases = _aliasrules.buildmap(ui.configitems('revsetalias'))
+def expandaliases(tree, aliases, warn=None):
+"""Expand aliases in a tree, aliases is a list of (name, value) tuples"""
+aliases = _aliasrules.buildmap(aliases)
 tree = _aliasrules.expand(aliases, tree)
 # warn about problematic (but not referred) aliases
-for name, alias in sorted(aliases.iteritems()):
-if alias.error and not alias.warned:
-ui.warn(_('warning: %s\n') % (alias.error))
-alias.warned = True
+if warn is not None:
+for name, alias in sorted(aliases.iteritems()):
+if alias.error and not alias.warned:
+warn(_('warning: %s\n') % (alias.error))
+alias.warned = True
 return tree
 
diff --git a/tests/test-revset.t b/tests/test-revset.t
--- a/tests/test-revset.t
+++ b/tests/test-revset.t
@@ -4260,3 +4260,26 @@ 

[PATCH 6 of 6 V2] histedit: migrate to scmutil.cleanupnodes (BC)

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1498515971 25200
#  Mon Jun 26 15:26:11 2017 -0700
# Node ID 5844ab9ea01f0fec2a9885bb03918d34b534d374
# Parent  8beac6dfe217dfabf51de371e04c024ad30406dd
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 5844ab9ea01f
histedit: migrate to scmutil.cleanupnodes (BC)

This is marked as BC because the strip backup file name has changed.

Aside from exciting code removals, there are some output changes explained
below:

  - "histedit: moving bookmarks X from Y to Z" no longer gets printed with
--verbose. This is more consistent with other commands, like "commit"
won't show bookmark movement message. The bookmark movement message is
still available via --debug.
  - There is only one backup file per command invocation, instead of two.
It is cleaner to just put all removed nodes in one file.
  - There are some debugobsolete ordering changes. That's just some
implementation detail of cleanupnodes. It should not affect any end-user
experience.

diff --git a/hgext/histedit.py b/hgext/histedit.py
--- a/hgext/histedit.py
+++ b/hgext/histedit.py
@@ -1172,11 +1172,18 @@ def _finishhistedit(ui, repo, state):
 ui.debug(m % node.short(n))
 
-safecleanupnode(ui, repo, 'temp', tmpnodes)
-
 if not state.keep:
-if mapping:
-movebookmarks(ui, repo, mapping, state.topmost, ntm)
-# TODO update mq state
-safecleanupnode(ui, repo, 'replaced', mapping)
+movebookmarks(repo, state.topmost, ntm)
+toclean = mapping.copy()
+else:
+toclean = {}
+# tmpnodes do not have successors, add them to "toclean" dict
+for n in tmpnodes:
+if n not in toclean:
+toclean[n] = ()
+# remove entries about unknown nodes
+nodemap = repo.unfiltered().changelog.nodemap
+toclean = {k: v for k, v in toclean.items()
+   if k in nodemap and all(n in nodemap for n in v)}
+scmutil.cleanupnodes(repo, toclean, 'histedit')
 
 state.clear()
@@ -1542,44 +1549,19 @@ def processreplacement(state):
 return final, tmpnodes, new, newtopmost
 
-def movebookmarks(ui, repo, mapping, oldtopmost, newtopmost):
-"""Move bookmark from old to newly created node"""
-if not mapping:
-# if nothing got rewritten there is not purpose for this function
+def movebookmarks(repo, oldtopmost, newtopmost):
+"""Move bookmark from oldtopmost to newly created topmost.
+
+Most of the bookmark movement logic is handled by scmutil.cleanupnodes,
+only handle the special case here: topmost bookmark movement.
+"""
+if not oldtopmost or not newtopmost:
 return
-moves = []
-for bk, old in sorted(repo._bookmarks.iteritems()):
-if old == oldtopmost:
-# special case ensure bookmark stay on tip.
-#
-# This is arguably a feature and we may only want that for the
-# active bookmark. But the behavior is kept compatible with the old
-# version for now.
-moves.append((bk, newtopmost))
-continue
-base = old
-new = mapping.get(base, None)
-if new is None:
-continue
-while not new:
-# base is killed, trying with parent
-base = repo[base].p1().node()
-new = mapping.get(base, (base,))
-# nothing to move
-moves.append((bk, new[-1]))
-if moves:
-lock = tr = None
-try:
-lock = repo.lock()
-tr = repo.transaction('histedit')
+oldbmarks = repo.nodebookmarks(oldtopmost)
+if oldbmarks:
+with repo.transaction('histedit') as tr:
 marks = repo._bookmarks
-for mark, new in moves:
-old = marks[mark]
-ui.note(_('histedit: moving bookmarks %s from %s to %s\n')
-% (mark, node.short(old), node.short(new)))
-marks[mark] = new
+for name in oldbmarks:
+marks[name] = newtopmost
 marks.recordchange(tr)
-tr.close()
-finally:
-release(tr, lock)
 
 def cleanupnode(ui, repo, name, nodes):
@@ -1605,32 +1587,4 @@ def cleanupnode(ui, repo, name, nodes):
 repair.strip(ui, repo, c)
 
-def safecleanupnode(ui, repo, name, nodes):
-"""strip or obsolete nodes
-
-nodes could be either a set or dict which maps to replacements.
-nodes could be unknown (outside the repo).
-"""
-supportsmarkers = obsolete.isenabled(repo, obsolete.createmarkersopt)
-if supportsmarkers:
-if util.safehasattr(nodes, 'get'):
-# nodes is a dict-like mapping
-# use unfiltered repo for successors in case they are hidden
-urepo = repo.unfiltered()
-def getmarker(prec):
-succs = tuple(urepo[n] for n in 

[PATCH 5 of 6 V2] amend: use scmutil.cleanupnodes (BC)

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1498516108 25200
#  Mon Jun 26 15:28:28 2017 -0700
# Node ID 8beac6dfe217dfabf51de371e04c024ad30406dd
# Parent  46beedf52f30bb4ff4a9077c5b1868b45cddcbe6
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 8beac6dfe217
amend: use scmutil.cleanupnodes (BC)

This is marked as BC because the strip backup file name has changed.

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -38,5 +38,4 @@ from . import (
 pycompat,
 registrar,
-repair,
 revlog,
 revset,
@@ -2750,5 +2749,4 @@ def amend(ui, repo, commitfunc, old, ext
 ui.note(_('amending changeset %s\n') % old)
 base = old.p1()
-createmarkers = obsolete.isenabled(repo, obsolete.createmarkersopt)
 
 newid = None
@@ -2891,30 +2889,8 @@ def amend(ui, repo, commitfunc, old, ext
 # Reroute the working copy parent to the new changeset
 repo.setparents(newid, nullid)
-
-# Move bookmarks from old parent to amend commit
-bms = repo.nodebookmarks(old.node())
-if bms:
-marks = repo._bookmarks
-for bm in bms:
-ui.debug('moving bookmarks %r from %s to %s\n' %
- (marks, old.hex(), hex(newid)))
-marks[bm] = newid
-marks.recordchange(tr)
-#commit the whole amend process
-if createmarkers:
-# mark the new changeset as successor of the rewritten one
-new = repo[newid]
-obs = [(old, (new,))]
-if node:
-obs.append((ctx, ()))
-
-obsolete.createmarkers(repo, obs, operation='amend')
-if not createmarkers and newid != old.node():
-# Strip the intermediate commit (if there was one) and the amended
-# commit
-if node:
-ui.note(_('stripping intermediate changeset %s\n') % ctx)
-ui.note(_('stripping amended changeset %s\n') % old)
-repair.strip(ui, repo, old.node(), topic='amend-backup')
+mapping = {old.node(): (newid,)}
+if node:
+mapping[ctx.node()] = ()
+scmutil.cleanupnodes(repo, mapping, 'amend')
 return newid
 
diff --git a/tests/test-automv.t b/tests/test-automv.t
--- a/tests/test-automv.t
+++ b/tests/test-automv.t
@@ -163,5 +163,5 @@ mv/rm/add
   $ hg commit --amend -m 'amended'
   detected move of 1 files
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status --change . -C
   A b.txt
@@ -186,5 +186,5 @@ mv/rm/add/modif
   $ hg commit --amend -m 'amended'
   detected move of 1 files
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status --change . -C
   A b.txt
@@ -208,5 +208,5 @@ mv/rm/add/modif
   R a.txt
   $ hg commit --amend -m 'amended'
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status --change . -C
   A b.txt
@@ -230,5 +230,5 @@ mv/rm/add/modif/changethreshold
   $ hg commit --amend --config automv.similarity='60' -m 'amended'
   detected move of 1 files
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status --change . -C
   A b.txt
@@ -249,5 +249,5 @@ mv
   ? b.txt
   $ hg commit --amend -m 'amended'
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status -C
   ! a.txt
@@ -271,5 +271,5 @@ mv/rm/add/notincommitfiles
   R a.txt
   $ hg commit --amend -m 'amended' d.txt
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status --change . -C
   A c.txt
@@ -280,5 +280,5 @@ mv/rm/add/notincommitfiles
   $ hg commit --amend -m 'amended'
   detected move of 1 files
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status --change . -C
   A b.txt
@@ -302,5 +302,5 @@ mv/rm/add/--no-automv
   R a.txt
   $ hg commit --amend -m 'amended' --no-automv
-  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend-backup.hg 
(glob)
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/*-amend.hg (glob)
   $ hg status 

[PATCH 3 of 6 V2] rebase: use scmutil.cleanupnodes (issue5606) (BC)

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1499478706 25200
#  Fri Jul 07 18:51:46 2017 -0700
# Node ID 4058f9bd7f385f065a9e91f6443bd2c30f9e8424
# Parent  f43cf4cf4de91f5ddae722062aa2b689a3c2e75b
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 4058f9bd7f38
rebase: use scmutil.cleanupnodes (issue5606) (BC)

This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies
the code and makes rebase code reusable inside a transaction.

This is a BC because the backup file is no longer strip-backup/*-backup.hg,
but strip-backup/*-rebase.hg. The latter looks more reasonable since the
directory name is "strip-backup" so there is no need to repeat "backup".

I think the backup file name change is probably fine as a BC, since we have
changed it before (aa4a1672583e) and didn't get complains. The end result
of this series will be a much more consistent and unified backup names:

  command  | old backup file suffix   | new backup file suffix
  ---
  amend| amend-backup.hg  | amend.hg
  histedit | backup.hg (could be 2 files) | histedit.hg (single file)
  rebase   | backup.hg| rebase.hg
  strip| backup.hg| backup.hg

(note: backup files are under .hg/strip-backup)

It also fixes issue5606 as a side effect because the new "delayedstrip" code
path will carefully examine nodes (safestriproots) to make sure orphaned
changesets won't get stripped by accident.

Some warning messages are changed to the new "warning: orphaned descendants
detected, not stripping HASHES", which provides more information about
exactly what changesets are left behind.

Another minor behavior change is when there is an obsoleted changeset with a
successor in the destination branch, bookmarks pointing to that obsoleted
changeset will not be moved. I have commented in test-rebase-obsolete.t
explaining why that is more desirable.

diff --git a/hgext/rebase.py b/hgext/rebase.py
--- a/hgext/rebase.py
+++ b/hgext/rebase.py
@@ -140,5 +140,4 @@ class rebaseruntime(object):
 self.state = {}
 self.activebookmark = None
-self.currentbookmarks = None
 self.dest = None
 self.skipped = set()
@@ -365,6 +364,5 @@ class rebaseruntime(object):
   inclusive=True)
 
-# Keep track of the current bookmarks in order to reset them later
-self.currentbookmarks = repo._bookmarks.copy()
+# Keep track of the active bookmarks in order to reset them later
 self.activebookmark = self.activebookmark or repo._activebookmark
 if self.activebookmark:
@@ -499,17 +497,4 @@ class rebaseruntime(object):
 updatemq(repo, self.state, self.skipped, **opts)
 
-if self.currentbookmarks:
-# Nodeids are needed to reset bookmarks
-nstate = {}
-for k, v in self.state.iteritems():
-if v > nullmerge and v != k:
-nstate[repo[k].node()] = repo[v].node()
-elif v == revprecursor:
-succ = self.obsoletenotrebased[k]
-nstate[repo[k].node()] = repo[succ].node()
-# XXX this is the same as dest.node() for the non-continue path --
-# this should probably be cleaned up
-destnode = repo[self.dest].node()
-
 # restore original working directory
 # (we do this before stripping)
@@ -524,12 +509,4 @@ class rebaseruntime(object):
 hg.updaterepo(repo, newwd, False)
 
-if self.currentbookmarks:
-with repo.transaction('bookmark') as tr:
-updatebookmarks(repo, destnode, nstate,
-self.currentbookmarks, tr)
-if self.activebookmark not in repo._bookmarks:
-# active bookmark was divergent one and has been deleted
-self.activebookmark = None
-
 if not self.keepf:
 collapsedas = None
@@ -547,5 +524,5 @@ class rebaseruntime(object):
 ui.note(_("%d revisions have been skipped\n") % skippedlen)
 
-if (self.activebookmark and
+if (self.activebookmark and self.activebookmark in repo._bookmarks and
 repo['.'].node() == repo._bookmarks[self.activebookmark]):
 bookmarks.activate(repo, self.activebookmark)
@@ -1090,14 +1067,4 @@ def updatemq(repo, state, skipped, **opt
 mq.savedirty()
 
-def updatebookmarks(repo, destnode, nstate, originalbookmarks, tr):
-'Move bookmarks to their correct changesets, and delete divergent ones'
-marks = repo._bookmarks
-for k, v in originalbookmarks.iteritems():
-if v in nstate:
-# update the bookmarks for revs that have moved
-marks[k] = nstate[v]
-

[PATCH 2 of 6 V2] scmutil: make cleanupnodes delete divergent bookmarks

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1498508031 25200
#  Mon Jun 26 13:13:51 2017 -0700
# Node ID f43cf4cf4de91f5ddae722062aa2b689a3c2e75b
# Parent  997d39aaaceb787983a8d61424d67ef178a7c02c
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r f43cf4cf4de9
scmutil: make cleanupnodes delete divergent bookmarks

cleanupnodes takes care of bookmark movement, and bookmark movement could
cause bookmark divergent resolution as a side effect. This patch adds such
bookmark divergent resolution logic so future rebase migration will be
easier.

The revset is carefully written to be equivalent to what rebase does today.
Although I think it might make sense to remove divergent bookmarks more
aggressively, for example:

F   book@1
|
E   book@2
|
| D book
| |
| C
|/
B   book@3
|
A

When rebase -s C -d E, "book@1" will be removed, "book@3" will be kept,
and the end result is:

D   book
|
C
|
F
|
E   book@2 (?)
|
B   book@3
|
A

The question is should we keep book@2? The current logic keeps it. If we
choose not to (makes some sense to me), the "deleterevs" revset could be
simplified to "newnode % oldnode".

For now, I just make it compatible with the existing behavior. If we want to
make the "deleterevs" revset simpler, we can always do it in the future.

diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -568,4 +568,14 @@ def origpath(ui, repo, filepath):
 return fullorigpath + ".orig"
 
+class _containsnode(object):
+"""proxy __contains__(node) to container.__contains__ which accepts revs"""
+
+def __init__(self, repo, revcontainer):
+self._torev = repo.changelog.rev
+self._revcontains = revcontainer.__contains__
+
+def __contains__(self, node):
+return self._revcontains(self._torev(node))
+
 def cleanupnodes(repo, mapping, operation):
 """do common cleanups when old nodes are replaced by new nodes
@@ -584,15 +594,14 @@ def cleanupnodes(repo, mapping, operatio
 bmarks = repo._bookmarks
 bmarkchanged = False
+allnewnodes = [n for ns in mapping.values() for n in ns]
 for oldnode, newnodes in mapping.items():
 oldbmarks = repo.nodebookmarks(oldnode)
 if not oldbmarks:
 continue
+from . import bookmarks # avoid import cycle
 bmarkchanged = True
 if len(newnodes) > 1:
-heads = list(repo.set('heads(%ln)', newnodes))
-if len(heads) != 1:
-raise error.ProgrammingError(
-'cannot figure out bookmark movement')
-newnode = heads[0].node()
+# usually a split, take the one with biggest rev number
+newnode = next(repo.set('max(%ln)', newnodes)).node()
 elif len(newnodes) == 0:
 # move bookmark backwards
@@ -607,6 +616,11 @@ def cleanupnodes(repo, mapping, operatio
 repo.ui.debug('moving bookmarks %r from %s to %s\n' %
   (oldbmarks, hex(oldnode), hex(newnode)))
+# Delete divergent bookmarks being parents of related newnodes
+deleterevs = repo.revs('parents(roots(%ln & (::%n))) - 
parents(%n)',
+   allnewnodes, newnode, oldnode)
+deletenodes = _containsnode(repo, deleterevs)
 for name in oldbmarks:
 bmarks[name] = newnode
+bookmarks.deletedivergent(repo, deletenodes, name)
 if bmarkchanged:
 bmarks.recordchange(tr)
diff --git a/tests/test-strip.t b/tests/test-strip.t
--- a/tests/test-strip.t
+++ b/tests/test-strip.t
@@ -1003,4 +1003,7 @@ Test high-level scmutil.cleanupnodes API
   > hg bookmark -i -r $i b-$i
   > done
+  $ hg bookmark -i -r E 'b-F@divergent1'
+  $ hg bookmark -i -r H 'b-F@divergent2'
+  $ hg bookmark -i -r G 'b-F@divergent3'
   $ cp -R . ../scmutilcleanup.obsstore
 
@@ -1026,5 +1029,5 @@ Test high-level scmutil.cleanupnodes API
   
   $ hg log -G -T '{rev}:{node|short} {desc} {bookmarks}' -r 'sort(all(), topo)'
-  o  8:1473d4b996d1 G2 b-G
+  o  8:1473d4b996d1 G2 b-F@divergent3 b-G
   |
   | o  7:d94e89b773b6 F2 b-F
@@ -1032,5 +1035,5 @@ Test high-level scmutil.cleanupnodes API
   | o  5:7fe5bac4c918 H
   |/|
-  | o  3:7fb047a69f22 E
+  | o  3:7fb047a69f22 E b-F@divergent1
   | |
   | | o  6:7c78f703e465 D2 b-D
@@ -1049,4 +1052,6 @@ Test high-level scmutil.cleanupnodes API
  b-D   6:7c78f703e465
  b-F   7:d94e89b773b6
+ b-F@divergent13:7fb047a69f22
+ b-F@divergent38:1473d4b996d1
  b-G   8:1473d4b996d1
  b-I   0:426bada5c675
@@ -1067,5 +1072,5 @@ we have reusable code here
   $ rm 

[PATCH 1 of 6 V2] scmutil: make cleanupnodes handle filtered node

[Jun Wu]

# HG changeset patch
# User Jun Wu 
# Date 1498514917 25200
#  Mon Jun 26 15:08:37 2017 -0700
# Node ID 997d39aaaceb787983a8d61424d67ef178a7c02c
# Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r 997d39aaaceb
scmutil: make cleanupnodes handle filtered node

In some valid usecases, the "mapping" received by scmutil.cleanupnodes have
filtered nodes. Use unfiltered repo to access them correctly.

The added test case will fail with the old cleanupnodes code.

This is important to migrate histedit to use the cleanupnodes API.

diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -620,7 +620,10 @@ def cleanupnodes(repo, mapping, operatio
 # some obsstore logic.
 # NOTE: the filtering and sorting might belong to createmarkers.
-isobs = repo.obsstore.successors.__contains__
-sortfunc = lambda ns: repo.changelog.rev(ns[0])
-rels = [(repo[n], (repo[m] for m in s))
+# Unfiltered repo is needed since nodes in mapping might be hidden.
+unfi = repo.unfiltered()
+isobs = unfi.obsstore.successors.__contains__
+torev = unfi.changelog.rev
+sortfunc = lambda ns: torev(ns[0])
+rels = [(unfi[n], (unfi[m] for m in s))
 for n, s in sorted(mapping.items(), key=sortfunc)
 if s or not isobs(n)]
diff --git a/tests/test-obsolete-divergent.t b/tests/test-obsolete-divergent.t
--- a/tests/test-obsolete-divergent.t
+++ b/tests/test-obsolete-divergent.t
@@ -11,4 +11,6 @@ Enable obsolete
   > [experimental]
   > evolution=createmarkers
+  > [extensions]
+  > drawdag=$TESTDIR/drawdag.py
   > [alias]
   > debugobsolete = debugobsolete -d '0 0'
@@ -618,2 +620,47 @@ successors-set. (report [A,B] not [A] + 
 
   $ cd ..
+
+Use scmutil.cleanupnodes API to create divergence
+
+  $ hg init cleanupnodes
+  $ cd cleanupnodes
+  $ hg debugdrawdag <<'EOS'
+  >   B1  B3 B4
+  >   | \|
+  >   A  Z
+  > EOS
+
+  $ hg update -q B1
+  $ echo 3 >> B
+  $ hg commit --amend -m B2
+  $ cat > $TESTTMP/scmutilcleanup.py < from mercurial import registrar, scmutil
+  > cmdtable = {}
+  > command = registrar.command(cmdtable)
+  > @command('cleanup')
+  > def cleanup(ui, repo):
+  > def node(expr):
+  > unfi = repo.unfiltered()
+  > rev = unfi.revs(expr).first()
+  > return unfi.changelog.node(rev)
+  > with repo.wlock(), repo.lock(), repo.transaction('delayedstrip'):
+  > mapping = {node('desc(B1)'): [node('desc(B3)')],
+  >node('desc(B3)'): [node('desc(B4)')]}
+  > scmutil.cleanupnodes(repo, mapping, 'test')
+  > EOF
+
+  $ rm .hg/localtags
+  $ hg cleanup --config extensions.t=$TESTTMP/scmutilcleanup.py
+  $ hg log -G -T '{rev}:{node|short} {desc} {troubles}' -r 'sort(all(), topo)'
+  @  5:1a2a9b5b0030 B2 divergent
+  |
+  | o  4:70d5a63ca112 B4 divergent
+  | |
+  | o  1:48b9aae0607f Z
+  |
+  o  0:426bada5c675 A
+  
+  $ hg debugobsolete
+  a178212c3433c4e77b573f6011e29affb8aefa33 
1a2a9b5b0030632400aa78e00388c20f99d3ec44 0 (Thu Jan 01 00:00:00 1970 +) 
{'user': 'test'}
+  a178212c3433c4e77b573f6011e29affb8aefa33 
ad6478fb94ecec98b86daae98722865d494ac561 0 (Thu Jan 01 00:00:00 1970 +) 
{'user': 'test'}
+  ad6478fb94ecec98b86daae98722865d494ac561 
70d5a63ca112acb3764bc1d7320ca90ea688d671 0 (Thu Jan 01 00:00:00 1970 +) 
{'user': 'test'}
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] template: rename successorssets template into successorgroup

[Yuya Nishihara]

On Fri, 07 Jul 2017 21:07:18 +0200, Boris Feld wrote:
> # HG changeset patch
> # User Boris Feld 
> # Date 1499454363 -7200
> #  Fri Jul 07 21:06:03 2017 +0200
> # Node ID 508801f7cd1304488b0d9ebf02a76be030608b21
> # Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
> # EXP-Topic renamesuccessosrssetstemplate
> template: rename successorssets template into successorgroup
> 
> The new name seems better and easier to remember for users.
> 
> diff -r e714159860fd -r 508801f7cd13 mercurial/templatekw.py
> --- a/mercurial/templatekw.py Fri Jul 07 08:33:10 2017 +0200
> +++ b/mercurial/templatekw.py Fri Jul 07 21:06:03 2017 +0200
> @@ -602,8 +602,8 @@
> lambda x: {'ctx': repo[x], 'revcache': {}},
> lambda d: _formatrevnode(d['ctx']))
>  
> -@templatekeyword("successorssets")
> -def showsuccessorssets(repo, ctx, **args):
> +@templatekeyword("successorgroup")
> +def showsuccessorgroup(repo, ctx, **args):
>  """Returns a string of sets of successors for a changectx

Can we rename it to "successorgroups" (plural) as it's the convention of
templatekw? The inner list should be renamed to "successorgroup" or "group"
as well.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 5] template: add successors template

[Yuya Nishihara]

On Fri, 07 Jul 2017 09:35:48 -0700, Sean Farley wrote:
> Yuya Nishihara  writes:
> > On Thu, 06 Jul 2017 11:05:22 -0700, Sean Farley wrote:
> >> Augie Fackler  writes:
> >> > On Wed, Jul 05, 2017 at 10:53:58PM +0200, Boris Feld wrote:
> >> >> # HG changeset patch
> >> >> # User Boris Feld 
> >> >> # Date 1499073720 -7200
> >> >> #  Mon Jul 03 11:22:00 2017 +0200
> >> >> # Node ID 82e2b4eb96b573dde890d725d758dbbc49407133
> >> >> # Parent  870bfaafd90e030b85b869922050be98f000a9a9
> >> >> # EXP-Topic successorstemplate
> >> >> template: add successors template
> >> >
> >> > queued, thanks
> >> >
> >> >>
> >> >> Add a 'successorssets' template that returns the list of all closest 
> >> >> known
> >> >> sucessorssets for a changectx. The elements of the list are changesets.
> >> >
> >> > I'm not...super in love with the name successorssets, but I have no
> >> > better ideas. I'd welcome some bikeshedding in the next ten days.
> >> 
> >> Off the top of my head:
> >> 
> >> successorgroup
> >> successorlike
> >> similarsuccessors
> >> successorkin
> >
> > No idea which is better, but a name like "similarsuccessors" might be nice
> > to justify calling the inner list as "successors".
> >
> >   {similarsuccessors % "{successors % ...}"}
> >  ^^
> >   sounds okay, and its actually a partial list of successors
> >
> >   {successorgroup % "{group % ...}"}
> >   ^
> >   calling it "successors" seems a bit odd because "group" is 
> > noun
> 
> I like similarsuccessors, fwiw. Also, "successors" is a noun as well.

I meant "successor" in "successorgroup" is adjective, so can't be a name
pointing to each element.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] check-code: prohibit `if False` antipattern

[Sean Farley]

Augie Fackler  writes:

> # HG changeset patch
> # User Augie Fackler 
> # Date 1499454671 14400
> #  Fri Jul 07 15:11:11 2017 -0400
> # Node ID 8a0a2d7fd76b56e480b667da437d9bf86188
> # Parent  0bb8da5f14431d5e648cd548c9512c48bd2d5b9c
> check-code: prohibit `if False` antipattern

Sweet cleanup, dude! Queued!


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

Re: [PATCH] template: rename successorssets template into successorgroup

[Sean Farley]

Boris Feld  writes:

> # HG changeset patch
> # User Boris Feld 
> # Date 1499454363 -7200
> #  Fri Jul 07 21:06:03 2017 +0200
> # Node ID 508801f7cd1304488b0d9ebf02a76be030608b21
> # Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
> # EXP-Topic renamesuccessosrssetstemplate
> template: rename successorssets template into successorgroup
>
> The new name seems better and easier to remember for users.

Looks good, queued!


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

[PATCH 2 of 3] convert: remove `if False` block

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1499454503 14400
#  Fri Jul 07 15:08:23 2017 -0400
# Node ID 0bb8da5f14431d5e648cd548c9512c48bd2d5b9c
# Parent  6b6be532c678c9e7932476cb0350b0e10b9fb194
convert: remove `if False` block

This code has never run since its introduction on July 18th,
2007. It's time for it to go.

diff --git a/hgext/convert/transport.py b/hgext/convert/transport.py
--- a/hgext/convert/transport.py
+++ b/hgext/convert/transport.py
@@ -81,11 +81,6 @@ class SvnRaTransport(object):
 if ra is None or not util.safehasattr(svn.ra, 'reparent'):
 self.client = svn.client.create_context(self.pool)
 ab = _create_auth_baton(self.pool)
-if False:
-svn.core.svn_auth_set_parameter(
-ab, svn.core.SVN_AUTH_PARAM_DEFAULT_USERNAME, 
self.username)
-svn.core.svn_auth_set_parameter(
-ab, svn.core.SVN_AUTH_PARAM_DEFAULT_PASSWORD, 
self.password)
 self.client.auth_baton = ab
 global svn_config
 if svn_config is None:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 3 of 3] check-code: prohibit `if False` antipattern

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1499454671 14400
#  Fri Jul 07 15:11:11 2017 -0400
# Node ID 8a0a2d7fd76b56e480b667da437d9bf86188
# Parent  0bb8da5f14431d5e648cd548c9512c48bd2d5b9c
check-code: prohibit `if False` antipattern

diff --git a/contrib/check-code.py b/contrib/check-code.py
--- a/contrib/check-code.py
+++ b/contrib/check-code.py
@@ -301,6 +301,7 @@ pypats = [
  "comparison with singleton, use 'is' or 'is not' instead"),
 (r'^\s*(while|if) [01]:',
  "use True/False for constant Boolean expression"),
+(r'^\s*if False(:| +and)', 'Remove code instead of using `if False`'),
 (r'(?:(?https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 3] filterpyflakes: move self-test into test file

[Augie Fackler]

# HG changeset patch
# User Augie Fackler 
# Date 1499454456 14400
#  Fri Jul 07 15:07:36 2017 -0400
# Node ID 6b6be532c678c9e7932476cb0350b0e10b9fb194
# Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
filterpyflakes: move self-test into test file

This will avoid a false positive on an upcoming check-code rule.

diff --git a/tests/filterpyflakes.py b/tests/filterpyflakes.py
--- a/tests/filterpyflakes.py
+++ b/tests/filterpyflakes.py
@@ -35,7 +35,3 @@ for line in sys.stdin:
 for line in lines:
 sys.stdout.write(line)
 print()
-
-# self test of "undefined name" detection
-if False:
-print(undefinedname)
diff --git a/tests/test-check-pyflakes.t b/tests/test-check-pyflakes.t
--- a/tests/test-check-pyflakes.t
+++ b/tests/test-check-pyflakes.t
@@ -6,10 +6,16 @@
 run pyflakes on all tracked files ending in .py or without a file ending
 (skipping binary file random-seed)
 
+  $ cat > test.py < print(undefinedname)
+  > EOF
+  $ pyflakes test.py 2>/dev/null | "$TESTDIR/filterpyflakes.py"
+  test.py:1: undefined name 'undefinedname'
+  
+
   $ testrepohg locate 'set:**.py or grep("^#!.*python")' \
   > -X hgext/fsmonitor/pywatchman \
   > -X mercurial/pycompat.py -X contrib/python-zstandard \
   > 2>/dev/null \
   > | xargs pyflakes 2>/dev/null | "$TESTDIR/filterpyflakes.py"
-  tests/filterpyflakes.py:41: undefined name 'undefinedname'
   
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] template: rename successorssets template into successorgroup

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499454363 -7200
#  Fri Jul 07 21:06:03 2017 +0200
# Node ID 508801f7cd1304488b0d9ebf02a76be030608b21
# Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
# EXP-Topic renamesuccessosrssetstemplate
template: rename successorssets template into successorgroup

The new name seems better and easier to remember for users.

diff -r e714159860fd -r 508801f7cd13 mercurial/templatekw.py
--- a/mercurial/templatekw.py   Fri Jul 07 08:33:10 2017 +0200
+++ b/mercurial/templatekw.py   Fri Jul 07 21:06:03 2017 +0200
@@ -602,8 +602,8 @@
lambda x: {'ctx': repo[x], 'revcache': {}},
lambda d: _formatrevnode(d['ctx']))
 
-@templatekeyword("successorssets")
-def showsuccessorssets(repo, ctx, **args):
+@templatekeyword("successorgroup")
+def showsuccessorgroup(repo, ctx, **args):
 """Returns a string of sets of successors for a changectx
 
 Format used is: [ctx1, ctx2], [ctx3] if ctx has been splitted into ctx1 and
diff -r e714159860fd -r 508801f7cd13 tests/test-obsmarker-template.t
--- a/tests/test-obsmarker-template.t   Fri Jul 07 08:33:10 2017 +0200
+++ b/tests/test-obsmarker-template.t   Fri Jul 07 21:06:03 2017 +0200
@@ -17,9 +17,9 @@
   > {if(predecessors, "\n  semi-colon: {join(predecessors, "; ")}")}\
   > {if(predecessors, "\n  json: {predecessors|json}")}\
   > {if(predecessors, "\n  map: {join(predecessors % "{rev}:{node}", " 
")}")}\
-  > {if(successorssets, "\n  Successors: {successorssets}")}\
-  > {if(successorssets, "\n  multi-line: {join(successorssets, "\n  
multi-line: ")}")}\
-  > {if(successorssets, "\n  json: {successorssets|json}")}\n'
+  > {if(successorgroup, "\n  Successors: {successorgroup}")}\
+  > {if(successorgroup, "\n  multi-line: {join(successorgroup, "\n  
multi-line: ")}")}\
+  > {if(successorgroup, "\n  json: {successorgroup|json}")}\n'
   > EOF
 
 Test templates on amended commit
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 5] template: add successors template

[Boris Feld]

On Fri, 2017-07-07 at 14:52 -0400, Augie Fackler wrote:
> I think successorgroup is a bit better as well. Can someone mail a
> followup?

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

[PATCH 07 of 10] configitems: register the 'bugzilla.fixregexp' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414616 -7200
#  Fri Jul 07 10:03:36 2017 +0200
# Node ID 19f7670da89197d4770c474f65bcc8427e1e07ad
# Parent  dcec97037a786b460a7705b00cb2821568bb5842
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.fixregexp' config

diff -r dcec97037a78 -r 19f7670da891 hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:34 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:36 2017 +0200
@@ -337,6 +337,9 @@
 configitem('bugzilla', 'db',
 default='bugs',
 )
+configitem('bugzilla', 'fixregexp',
+default=lambda: bugzilla._default_fix_re,
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -975,8 +978,7 @@
 self.ui.config('bugzilla', 'regexp',
bugzilla._default_bug_re), re.IGNORECASE)
 self.fix_re = re.compile(
-self.ui.config('bugzilla', 'fixregexp',
-   bugzilla._default_fix_re), re.IGNORECASE)
+self.ui.config('bugzilla', 'fixregexp'), re.IGNORECASE)
 self.split_re = re.compile(r'\D+')
 
 def find_bugs(self, ctx):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 01 of 10] configitems: register the 'bugzilla.apikey' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414602 -7200
#  Fri Jul 07 10:03:22 2017 +0200
# Node ID ff78bedcf36af5517172a74a19f2a223c0128c4f
# Parent  89796a25d4bb91fb418ad3e70faad2c586902ffb
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.apikey' config

diff -r 89796a25d4bb -r ff78bedcf36a hgext/bugzilla.py
--- a/hgext/bugzilla.py Mon Jul 03 11:22:00 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:22 2017 +0200
@@ -303,6 +303,7 @@
 cmdutil,
 error,
 mail,
+registrar,
 url,
 util,
 )
@@ -315,6 +316,13 @@
 # leave the attribute unspecified.
 testedwith = 'ships-with-hg-core'
 
+configtable = {}
+configitem = registrar.configitem(configtable)
+
+configitem('bugzilla', 'apikey',
+default='',
+)
+
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
 
@@ -800,7 +808,7 @@
 bz = self.ui.config('bugzilla', 'bzurl',
 'http://localhost/bugzilla/')
 self.bzroot = '/'.join([bz, 'rest'])
-self.apikey = self.ui.config('bugzilla', 'apikey', '')
+self.apikey = self.ui.config('bugzilla', 'apikey')
 self.user = self.ui.config('bugzilla', 'user', 'bugs')
 self.passwd = self.ui.config('bugzilla', 'password')
 self.fixstatus = self.ui.config('bugzilla', 'fixstatus', 'RESOLVED')
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 10 of 10] configitems: register the 'bugzilla.host' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414641 -7200
#  Fri Jul 07 10:04:01 2017 +0200
# Node ID 686908f9b45d95c674edccd189f3c6f4814dbfb4
# Parent  f1eb434550a89f9705be8835409e1e0e6ff7a035
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.host' config

diff -r f1eb434550a8 -r 686908f9b45d hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:57 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:04:01 2017 +0200
@@ -346,6 +346,9 @@
 configitem('bugzilla', 'fixstatus',
 default='RESOLVED',
 )
+configitem('bugzilla', 'host',
+default='localhost',
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -421,7 +424,7 @@
 
 bzaccess.__init__(self, ui)
 
-host = self.ui.config('bugzilla', 'host', 'localhost')
+host = self.ui.config('bugzilla', 'host')
 user = self.ui.config('bugzilla', 'user', 'bugs')
 passwd = self.ui.config('bugzilla', 'password')
 db = self.ui.config('bugzilla', 'db')
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 04 of 10] configitems: register the 'bugzilla.bzurl' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414608 -7200
#  Fri Jul 07 10:03:28 2017 +0200
# Node ID 3246453035686bafc15f262bf35f7cb18f755f59
# Parent  afee98344d67275a6bf631fc89629ca3e46e7166
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.bzurl' config

diff -r afee98344d67 -r 324645303568 hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:26 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:28 2017 +0200
@@ -328,6 +328,9 @@
 configitem('bugzilla', 'bzemail',
 default=None,
 )
+configitem('bugzilla', 'bzurl',
+default='http://localhost/bugzilla/',
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -649,8 +652,7 @@
 def __init__(self, ui):
 bzaccess.__init__(self, ui)
 
-bzweb = self.ui.config('bugzilla', 'bzurl',
-   'http://localhost/bugzilla/')
+bzweb = self.ui.config('bugzilla', 'bzurl')
 bzweb = bzweb.rstrip("/") + "/xmlrpc.cgi"
 
 user = self.ui.config('bugzilla', 'user', 'bugs')
@@ -810,8 +812,7 @@
 """
 def __init__(self, ui):
 bzaccess.__init__(self, ui)
-bz = self.ui.config('bugzilla', 'bzurl',
-'http://localhost/bugzilla/')
+bz = self.ui.config('bugzilla', 'bzurl')
 self.bzroot = '/'.join([bz, 'rest'])
 self.apikey = self.ui.config('bugzilla', 'apikey')
 self.user = self.ui.config('bugzilla', 'user', 'bugs')
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 06 of 10] configitems: register the 'bugzilla.db' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414614 -7200
#  Fri Jul 07 10:03:34 2017 +0200
# Node ID dcec97037a786b460a7705b00cb2821568bb5842
# Parent  2a7fec2040efcbb15afa77caf58e2023755be38a
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.db' config

diff -r 2a7fec2040ef -r dcec97037a78 hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:31 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:34 2017 +0200
@@ -334,6 +334,9 @@
 configitem('bugzilla', 'bzuser',
 default=None,
 )
+configitem('bugzilla', 'db',
+default='bugs',
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -412,7 +415,7 @@
 host = self.ui.config('bugzilla', 'host', 'localhost')
 user = self.ui.config('bugzilla', 'user', 'bugs')
 passwd = self.ui.config('bugzilla', 'password')
-db = self.ui.config('bugzilla', 'db', 'bugs')
+db = self.ui.config('bugzilla', 'db')
 timeout = int(self.ui.config('bugzilla', 'timeout', 5))
 self.ui.note(_('connecting to %s:%s as %s, password %s\n') %
  (host, db, user, '*' * len(passwd)))
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 03 of 10] configitems: register the 'bugzilla.bzemail' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414606 -7200
#  Fri Jul 07 10:03:26 2017 +0200
# Node ID afee98344d67275a6bf631fc89629ca3e46e7166
# Parent  4802d0b9e2ef4906f7114f01eaf87711dcdf3c40
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.bzemail' config

diff -r 4802d0b9e2ef -r afee98344d67 hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:24 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:26 2017 +0200
@@ -325,6 +325,9 @@
 configitem('bugzilla', 'bzdir',
 default='/var/www/html/bugzilla',
 )
+configitem('bugzilla', 'bzemail',
+default=None,
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 08 of 10] configitems: register the 'bugzilla.fixresolution' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414740 -7200
#  Fri Jul 07 10:05:40 2017 +0200
# Node ID c272cde1e7f4353121b69cbda1ab254e89db81a2
# Parent  19f7670da89197d4770c474f65bcc8427e1e07ad
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.fixresolution' config

diff -r 19f7670da891 -r c272cde1e7f4 hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:36 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:05:40 2017 +0200
@@ -340,6 +340,9 @@
 configitem('bugzilla', 'fixregexp',
 default=lambda: bugzilla._default_fix_re,
 )
+configitem('bugzilla', 'fixresolution',
+default='FIXED',
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -668,8 +671,7 @@
 passwd = self.ui.config('bugzilla', 'password')
 
 self.fixstatus = self.ui.config('bugzilla', 'fixstatus', 'RESOLVED')
-self.fixresolution = self.ui.config('bugzilla', 'fixresolution',
-'FIXED')
+self.fixresolution = self.ui.config('bugzilla', 'fixresolution')
 
 self.bzproxy = xmlrpclib.ServerProxy(bzweb, self.transport(bzweb))
 ver = self.bzproxy.Bugzilla.version()['version'].split('.')
@@ -827,8 +829,7 @@
 self.user = self.ui.config('bugzilla', 'user', 'bugs')
 self.passwd = self.ui.config('bugzilla', 'password')
 self.fixstatus = self.ui.config('bugzilla', 'fixstatus', 'RESOLVED')
-self.fixresolution = self.ui.config('bugzilla', 'fixresolution',
-'FIXED')
+self.fixresolution = self.ui.config('bugzilla', 'fixresolution')
 
 def apiurl(self, targets, include_fields=None):
 url = '/'.join([self.bzroot] + [str(t) for t in targets])
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 09 of 10] configitems: register the 'bugzilla.fixstatus' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414637 -7200
#  Fri Jul 07 10:03:57 2017 +0200
# Node ID f1eb434550a89f9705be8835409e1e0e6ff7a035
# Parent  c272cde1e7f4353121b69cbda1ab254e89db81a2
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.fixstatus' config

diff -r c272cde1e7f4 -r f1eb434550a8 hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:05:40 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:57 2017 +0200
@@ -343,6 +343,9 @@
 configitem('bugzilla', 'fixresolution',
 default='FIXED',
 )
+configitem('bugzilla', 'fixstatus',
+default='RESOLVED',
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -670,7 +673,7 @@
 user = self.ui.config('bugzilla', 'user', 'bugs')
 passwd = self.ui.config('bugzilla', 'password')
 
-self.fixstatus = self.ui.config('bugzilla', 'fixstatus', 'RESOLVED')
+self.fixstatus = self.ui.config('bugzilla', 'fixstatus')
 self.fixresolution = self.ui.config('bugzilla', 'fixresolution')
 
 self.bzproxy = xmlrpclib.ServerProxy(bzweb, self.transport(bzweb))
@@ -828,7 +831,7 @@
 self.apikey = self.ui.config('bugzilla', 'apikey')
 self.user = self.ui.config('bugzilla', 'user', 'bugs')
 self.passwd = self.ui.config('bugzilla', 'password')
-self.fixstatus = self.ui.config('bugzilla', 'fixstatus', 'RESOLVED')
+self.fixstatus = self.ui.config('bugzilla', 'fixstatus')
 self.fixresolution = self.ui.config('bugzilla', 'fixresolution')
 
 def apiurl(self, targets, include_fields=None):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 05 of 10] configitems: register the 'bugzilla.bzuser' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414611 -7200
#  Fri Jul 07 10:03:31 2017 +0200
# Node ID 2a7fec2040efcbb15afa77caf58e2023755be38a
# Parent  3246453035686bafc15f262bf35f7cb18f755f59
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.bzuser' config

diff -r 324645303568 -r 2a7fec2040ef hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:28 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:31 2017 +0200
@@ -331,6 +331,9 @@
 configitem('bugzilla', 'bzurl',
 default='http://localhost/bugzilla/',
 )
+configitem('bugzilla', 'bzuser',
+default=None,
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 02 of 10] configitems: register the 'bugzilla.bzdir' config

[Boris Feld]

# HG changeset patch
# User Octobus 
# Date 1499414604 -7200
#  Fri Jul 07 10:03:24 2017 +0200
# Node ID 4802d0b9e2ef4906f7114f01eaf87711dcdf3c40
# Parent  ff78bedcf36af5517172a74a19f2a223c0128c4f
# EXP-Topic config.register.bugzilla
configitems: register the 'bugzilla.bzdir' config

diff -r ff78bedcf36a -r 4802d0b9e2ef hgext/bugzilla.py
--- a/hgext/bugzilla.py Fri Jul 07 10:03:22 2017 +0200
+++ b/hgext/bugzilla.py Fri Jul 07 10:03:24 2017 +0200
@@ -322,6 +322,9 @@
 configitem('bugzilla', 'apikey',
 default='',
 )
+configitem('bugzilla', 'bzdir',
+default='/var/www/html/bugzilla',
+)
 
 class bzaccess(object):
 '''Base class for access to Bugzilla.'''
@@ -457,8 +460,7 @@
 for id in bugs.keys():
 self.ui.status(_('  bug %s\n') % id)
 cmdfmt = self.ui.config('bugzilla', 'notify', self.default_notify)
-bzdir = self.ui.config('bugzilla', 'bzdir',
-   '/var/www/html/bugzilla')
+bzdir = self.ui.config('bugzilla', 'bzdir')
 try:
 # Backwards-compatible with old notify string, which
 # took one string. This will throw with a new format
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 5] template: add successors template

[Augie Fackler]

> On Jul 7, 2017, at 2:50 PM, Boris Feld  wrote:
> 
>> "successorsset" looks okay to me, since "set" and "group" are not
>> that much
>> different.
> 
> Successorgroup sound good to me, it is less implementation specific and
> might be easier to understand for users.

I think successorgroup is a bit better as well. Can someone mail a followup?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 5] template: add successors template

[Boris Feld]

On Fri, 2017-07-07 at 10:29 -0700, Jun Wu wrote:
> Excerpts from Sean Farley's message of 2017-07-06 11:05:22 -0700:
> > Augie Fackler  writes:
> > > On Wed, Jul 05, 2017 at 10:53:58PM +0200, Boris Feld wrote:
> > > I'm not...super in love with the name successorssets, but I have
> > > no
> > > better ideas. I'd welcome some bikeshedding in the next ten days.
> > 
> > Off the top of my head:
> > 
> > successorgroup
> > successorlike
> > similarsuccessors
> > successorkin
> 
> "group" looks better to me than "similar". "similar" sounds like
> there is
> some filtering logic that removes non-similar ones.

I agree with Jun that similar might send indicates that the successors
are selected or processed in a specific way.

> 
> "successorsset" looks okay to me, since "set" and "group" are not
> that much
> different.

Successorgroup sound good to me, it is less implementation specific and
might be easier to understand for users.

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

Re: [PATCH] summary: fix type of empty unresolved list

[Sean Farley]

Yuya Nishihara  writes:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1499436784 -32400
> #  Fri Jul 07 23:13:04 2017 +0900
> # Node ID de50a2f8fd984912893b6aea79cd0d7ab0b83299
> # Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
> summary: fix type of empty unresolved list
>
> It was okay because tested as a boolean prior to calling len(), but looked
> incorrect.

Makes sense. Queued!


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

Re: [PATCH 11 of 11 sparse V3] sparse: move post commit actions into core

[Sean Farley]

Gregory Szorc  writes:

> On Fri, Jul 7, 2017 at 11:42 AM, Martin von Zweigbergk <
> martinv...@google.com> wrote:
>
>> On Fri, Jul 7, 2017 at 11:39 AM, Sean Farley  wrote:
>> >
>> > Gregory Szorc  writes:
>> >
>> >> On Thu, Jul 6, 2017 at 10:16 PM, Martin von Zweigbergk <
>> >> martinv...@google.com> wrote:
>> >>
>> >>> On Thu, Jul 6, 2017 at 6:18 PM, Gregory Szorc > >
>> >>> wrote:
>> >>> > # HG changeset patch
>> >>> > # User Gregory Szorc 
>> >>> > # Date 1499379254 25200
>> >>> > #  Thu Jul 06 15:14:14 2017 -0700
>> >>> > # Node ID fe47ebda0b384aa1d3002c6db3c4bace60472337
>> >>> > # Parent  1c1a25d842854cbb2a7516136f7bcaab0d9f4539
>> >>> > sparse: move post commit actions into core
>> >>> >
>> >>> > Instead of wrapping committablectx.markcommitted(), we inline
>> >>> > the call into localrepository.commit(), which is the only place
>> >>> > we call markcommitted().
>> >>> >
>> >>> > The APIs and distribution of duties between
>> >>> > localrepository.commit() and committablecontext.markcommitted()
>> >>> > are unclear to me. As is the proper order for certain operations
>> >>> > to be performed. There is room to improve this code.
>> >>>
>> >>> 4fb92f14a97a (commit: factor out post-commit cleanup into workingctx,
>> >>> 2013-02-08) says that markcommitted() was created to prepare for
>> >>> in-memory merge. Given that, it seems more appropriate to leave the
>> >>> call to sparse.aftercommit() at the end of
>> >>> committablectx.markcommitted(), no? (I say "leave" because that's
>> >>> where it was essentially called from in the wrapper.)
>> >>>
>> >>> I'll queue 1-9 and let you think about this one a bit. Thanks!
>> >>>
>> >>
>> >> Looking at this more, I'm not sure committablectx is the proper place
>> for
>> >> it. This sparse code interacts with working directory state. If
>> >> committablectx (which is the base for memctx) is used outside of a
>> working
>> >> directory, it doesn't make a lot of sense to be touching the working
>> >> directory from an in-memory commit. localrepository.commit() does,
>> however,
>> >> only operate on working directories.
>> >>
>> >> Perhaps this code belongs in workingctx.markcommitted()? But then again,
>> >> committablectx.markcommitted() touches dirstate, which is specific to
>> the
>> >> working directory. So now I'm just confused as to what these various
>> >> contexts are for and what each should and should not do.
>> >
>> > Yes, anything touching the dirstate should be in workingctx. It was a
>> > misunderstanding on my part that committablectx ever got dirstate stuff.
>> >
>> >> I suppose I'll just preserve the code as part of
>> >> commitablectx.markcommitted() in the next patchbomb. We can always
>> clean it
>> >> up later if it is wrong.
>> >
>> > I have a series (I thought I sent it but it seems not) that cleans up
>> > all that mess. So, for clarity,
>> >
>> > - workingctx: anything touching the disk
>> > - memctx: anything in memory
>> > - committablectx: anything that is shared
>>
>> Makes sense. Greg, I'm still fine with leaving on committablectx for
>> now and moving to workingctx later.
>>
>
> Nah - I'll just move it straight to workingctx so we do this right.
>
> Thanks for the info, Sean! Please do send your series to clean this all up.

No prob :-) Will do after this week so that we don't conflict.


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

Re: [PATCH 3 of 3] vfs: rename auditvfs to proxyvfs

[Sean Farley]

Yuya Nishihara  writes:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1499438400 -32400
> #  Fri Jul 07 23:40:00 2017 +0900
> # Node ID a10abcecbd75a060cabea857458b7c921704cb4b
> # Parent  4249fe0f2a768bd556bd8e69e1b62baa20594190
> vfs: rename auditvfs to proxyvfs
>
> Since we've removed mustaudit property, auditvfs has no auditing business.
> It's just a utility class for vfs wrappers.

Looks like a good cleanup to me; queued!


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

Re: [PATCH 11 of 11 sparse V3] sparse: move post commit actions into core

[Gregory Szorc]

On Fri, Jul 7, 2017 at 11:42 AM, Martin von Zweigbergk <
martinv...@google.com> wrote:

> On Fri, Jul 7, 2017 at 11:39 AM, Sean Farley  wrote:
> >
> > Gregory Szorc  writes:
> >
> >> On Thu, Jul 6, 2017 at 10:16 PM, Martin von Zweigbergk <
> >> martinv...@google.com> wrote:
> >>
> >>> On Thu, Jul 6, 2017 at 6:18 PM, Gregory Szorc  >
> >>> wrote:
> >>> > # HG changeset patch
> >>> > # User Gregory Szorc 
> >>> > # Date 1499379254 25200
> >>> > #  Thu Jul 06 15:14:14 2017 -0700
> >>> > # Node ID fe47ebda0b384aa1d3002c6db3c4bace60472337
> >>> > # Parent  1c1a25d842854cbb2a7516136f7bcaab0d9f4539
> >>> > sparse: move post commit actions into core
> >>> >
> >>> > Instead of wrapping committablectx.markcommitted(), we inline
> >>> > the call into localrepository.commit(), which is the only place
> >>> > we call markcommitted().
> >>> >
> >>> > The APIs and distribution of duties between
> >>> > localrepository.commit() and committablecontext.markcommitted()
> >>> > are unclear to me. As is the proper order for certain operations
> >>> > to be performed. There is room to improve this code.
> >>>
> >>> 4fb92f14a97a (commit: factor out post-commit cleanup into workingctx,
> >>> 2013-02-08) says that markcommitted() was created to prepare for
> >>> in-memory merge. Given that, it seems more appropriate to leave the
> >>> call to sparse.aftercommit() at the end of
> >>> committablectx.markcommitted(), no? (I say "leave" because that's
> >>> where it was essentially called from in the wrapper.)
> >>>
> >>> I'll queue 1-9 and let you think about this one a bit. Thanks!
> >>>
> >>
> >> Looking at this more, I'm not sure committablectx is the proper place
> for
> >> it. This sparse code interacts with working directory state. If
> >> committablectx (which is the base for memctx) is used outside of a
> working
> >> directory, it doesn't make a lot of sense to be touching the working
> >> directory from an in-memory commit. localrepository.commit() does,
> however,
> >> only operate on working directories.
> >>
> >> Perhaps this code belongs in workingctx.markcommitted()? But then again,
> >> committablectx.markcommitted() touches dirstate, which is specific to
> the
> >> working directory. So now I'm just confused as to what these various
> >> contexts are for and what each should and should not do.
> >
> > Yes, anything touching the dirstate should be in workingctx. It was a
> > misunderstanding on my part that committablectx ever got dirstate stuff.
> >
> >> I suppose I'll just preserve the code as part of
> >> commitablectx.markcommitted() in the next patchbomb. We can always
> clean it
> >> up later if it is wrong.
> >
> > I have a series (I thought I sent it but it seems not) that cleans up
> > all that mess. So, for clarity,
> >
> > - workingctx: anything touching the disk
> > - memctx: anything in memory
> > - committablectx: anything that is shared
>
> Makes sense. Greg, I'm still fine with leaving on committablectx for
> now and moving to workingctx later.
>

Nah - I'll just move it straight to workingctx so we do this right.

Thanks for the info, Sean! Please do send your series to clean this all up.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 11 of 11 sparse V3] sparse: move post commit actions into core

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 11:39 AM, Sean Farley  wrote:
>
> Gregory Szorc  writes:
>
>> On Thu, Jul 6, 2017 at 10:16 PM, Martin von Zweigbergk <
>> martinv...@google.com> wrote:
>>
>>> On Thu, Jul 6, 2017 at 6:18 PM, Gregory Szorc 
>>> wrote:
>>> > # HG changeset patch
>>> > # User Gregory Szorc 
>>> > # Date 1499379254 25200
>>> > #  Thu Jul 06 15:14:14 2017 -0700
>>> > # Node ID fe47ebda0b384aa1d3002c6db3c4bace60472337
>>> > # Parent  1c1a25d842854cbb2a7516136f7bcaab0d9f4539
>>> > sparse: move post commit actions into core
>>> >
>>> > Instead of wrapping committablectx.markcommitted(), we inline
>>> > the call into localrepository.commit(), which is the only place
>>> > we call markcommitted().
>>> >
>>> > The APIs and distribution of duties between
>>> > localrepository.commit() and committablecontext.markcommitted()
>>> > are unclear to me. As is the proper order for certain operations
>>> > to be performed. There is room to improve this code.
>>>
>>> 4fb92f14a97a (commit: factor out post-commit cleanup into workingctx,
>>> 2013-02-08) says that markcommitted() was created to prepare for
>>> in-memory merge. Given that, it seems more appropriate to leave the
>>> call to sparse.aftercommit() at the end of
>>> committablectx.markcommitted(), no? (I say "leave" because that's
>>> where it was essentially called from in the wrapper.)
>>>
>>> I'll queue 1-9 and let you think about this one a bit. Thanks!
>>>
>>
>> Looking at this more, I'm not sure committablectx is the proper place for
>> it. This sparse code interacts with working directory state. If
>> committablectx (which is the base for memctx) is used outside of a working
>> directory, it doesn't make a lot of sense to be touching the working
>> directory from an in-memory commit. localrepository.commit() does, however,
>> only operate on working directories.
>>
>> Perhaps this code belongs in workingctx.markcommitted()? But then again,
>> committablectx.markcommitted() touches dirstate, which is specific to the
>> working directory. So now I'm just confused as to what these various
>> contexts are for and what each should and should not do.
>
> Yes, anything touching the dirstate should be in workingctx. It was a
> misunderstanding on my part that committablectx ever got dirstate stuff.
>
>> I suppose I'll just preserve the code as part of
>> commitablectx.markcommitted() in the next patchbomb. We can always clean it
>> up later if it is wrong.
>
> I have a series (I thought I sent it but it seems not) that cleans up
> all that mess. So, for clarity,
>
> - workingctx: anything touching the disk
> - memctx: anything in memory
> - committablectx: anything that is shared

Makes sense. Greg, I'm still fine with leaving on committablectx for
now and moving to workingctx later.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 11 of 11 sparse V3] sparse: move post commit actions into core

[Sean Farley]

Gregory Szorc  writes:

> On Thu, Jul 6, 2017 at 10:16 PM, Martin von Zweigbergk <
> martinv...@google.com> wrote:
>
>> On Thu, Jul 6, 2017 at 6:18 PM, Gregory Szorc 
>> wrote:
>> > # HG changeset patch
>> > # User Gregory Szorc 
>> > # Date 1499379254 25200
>> > #  Thu Jul 06 15:14:14 2017 -0700
>> > # Node ID fe47ebda0b384aa1d3002c6db3c4bace60472337
>> > # Parent  1c1a25d842854cbb2a7516136f7bcaab0d9f4539
>> > sparse: move post commit actions into core
>> >
>> > Instead of wrapping committablectx.markcommitted(), we inline
>> > the call into localrepository.commit(), which is the only place
>> > we call markcommitted().
>> >
>> > The APIs and distribution of duties between
>> > localrepository.commit() and committablecontext.markcommitted()
>> > are unclear to me. As is the proper order for certain operations
>> > to be performed. There is room to improve this code.
>>
>> 4fb92f14a97a (commit: factor out post-commit cleanup into workingctx,
>> 2013-02-08) says that markcommitted() was created to prepare for
>> in-memory merge. Given that, it seems more appropriate to leave the
>> call to sparse.aftercommit() at the end of
>> committablectx.markcommitted(), no? (I say "leave" because that's
>> where it was essentially called from in the wrapper.)
>>
>> I'll queue 1-9 and let you think about this one a bit. Thanks!
>>
>
> Looking at this more, I'm not sure committablectx is the proper place for
> it. This sparse code interacts with working directory state. If
> committablectx (which is the base for memctx) is used outside of a working
> directory, it doesn't make a lot of sense to be touching the working
> directory from an in-memory commit. localrepository.commit() does, however,
> only operate on working directories.
>
> Perhaps this code belongs in workingctx.markcommitted()? But then again,
> committablectx.markcommitted() touches dirstate, which is specific to the
> working directory. So now I'm just confused as to what these various
> contexts are for and what each should and should not do.

Yes, anything touching the dirstate should be in workingctx. It was a
misunderstanding on my part that committablectx ever got dirstate stuff.

> I suppose I'll just preserve the code as part of
> commitablectx.markcommitted() in the next patchbomb. We can always clean it
> up later if it is wrong.

I have a series (I thought I sent it but it seems not) that cleans up
all that mess. So, for clarity,

- workingctx: anything touching the disk
- memctx: anything in memory
- committablectx: anything that is shared


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

Re: [PATCH] commitextras: move fb's extension which add extras to a commit to core

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 11:33 AM, Sean Farley  wrote:
>
> Kevin Bullock  writes:
>
>>> On Jul 7, 2017, at 13:25, Martin von Zweigbergk via Mercurial-devel 
>>>  wrote:
>>>
>>> On Fri, Jul 7, 2017 at 11:23 AM, Sean Farley  wrote:

 Yuya Nishihara  writes:
>
> debugcommit seems fine.
>
> FWIW, --extra value will need some encoding handling depending on its
> type, e.g. convert labels to utf-8, but keep file path as bytes.

 Yeah, seems fine to me too. But was there any reason we're avoiding the
 path of new-thing-as-extension first, then into core second?
>>>
>>> If we decide to put it in debugcommit, we provide no BC guarantee
>>> (AFAIK), so we can remove it later if we see a reason. That buys us
>>> the same flexibility as having it in an extensions, it seems.
>>
>> Hmm, I'm not sure we throw out BC guarantees for debug commands. Per 
>> , there is 
>> somewhat of a gradient to the strength of BC guarantees, but as I read it, 
>> debug commands aren't exempt.
>>
>> Also just as a reminder for those following along, we only suspend the BC 
>> guarantees for extensions that are marked EXPERIMENTAL.
>
> Ah, yeah. Though, I might disagree a bit with debug* being BC that's
> another discussion entirely.

That's unclear to me too.

>
> For this case, it would seem that marking this as an EXPERIMENTAL
> extension that adds the 'debugcommit' command would cover all these
> points / issues?

I agree, that sounds like our safest bet.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] commitextras: move fb's extension which add extras to a commit to core

[Sean Farley]

Kevin Bullock  writes:

>> On Jul 7, 2017, at 13:25, Martin von Zweigbergk via Mercurial-devel 
>>  wrote:
>> 
>> On Fri, Jul 7, 2017 at 11:23 AM, Sean Farley  wrote:
>>> 
>>> Yuya Nishihara  writes:
 
 debugcommit seems fine.
 
 FWIW, --extra value will need some encoding handling depending on its
 type, e.g. convert labels to utf-8, but keep file path as bytes.
>>> 
>>> Yeah, seems fine to me too. But was there any reason we're avoiding the
>>> path of new-thing-as-extension first, then into core second?
>> 
>> If we decide to put it in debugcommit, we provide no BC guarantee
>> (AFAIK), so we can remove it later if we see a reason. That buys us
>> the same flexibility as having it in an extensions, it seems.
>
> Hmm, I'm not sure we throw out BC guarantees for debug commands. Per 
> , there is 
> somewhat of a gradient to the strength of BC guarantees, but as I read it, 
> debug commands aren't exempt.
>
> Also just as a reminder for those following along, we only suspend the BC 
> guarantees for extensions that are marked EXPERIMENTAL.

Ah, yeah. Though, I might disagree a bit with debug* being BC that's
another discussion entirely.

For this case, it would seem that marking this as an EXPERIMENTAL
extension that adds the 'debugcommit' command would cover all these
points / issues?


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

Re: [PATCH 11 of 11 sparse V3] sparse: move post commit actions into core

[Gregory Szorc]

On Thu, Jul 6, 2017 at 10:16 PM, Martin von Zweigbergk <
martinv...@google.com> wrote:

> On Thu, Jul 6, 2017 at 6:18 PM, Gregory Szorc 
> wrote:
> > # HG changeset patch
> > # User Gregory Szorc 
> > # Date 1499379254 25200
> > #  Thu Jul 06 15:14:14 2017 -0700
> > # Node ID fe47ebda0b384aa1d3002c6db3c4bace60472337
> > # Parent  1c1a25d842854cbb2a7516136f7bcaab0d9f4539
> > sparse: move post commit actions into core
> >
> > Instead of wrapping committablectx.markcommitted(), we inline
> > the call into localrepository.commit(), which is the only place
> > we call markcommitted().
> >
> > The APIs and distribution of duties between
> > localrepository.commit() and committablecontext.markcommitted()
> > are unclear to me. As is the proper order for certain operations
> > to be performed. There is room to improve this code.
>
> 4fb92f14a97a (commit: factor out post-commit cleanup into workingctx,
> 2013-02-08) says that markcommitted() was created to prepare for
> in-memory merge. Given that, it seems more appropriate to leave the
> call to sparse.aftercommit() at the end of
> committablectx.markcommitted(), no? (I say "leave" because that's
> where it was essentially called from in the wrapper.)
>
> I'll queue 1-9 and let you think about this one a bit. Thanks!
>

Looking at this more, I'm not sure committablectx is the proper place for
it. This sparse code interacts with working directory state. If
committablectx (which is the base for memctx) is used outside of a working
directory, it doesn't make a lot of sense to be touching the working
directory from an in-memory commit. localrepository.commit() does, however,
only operate on working directories.

Perhaps this code belongs in workingctx.markcommitted()? But then again,
committablectx.markcommitted() touches dirstate, which is specific to the
working directory. So now I'm just confused as to what these various
contexts are for and what each should and should not do.

I suppose I'll just preserve the code as part of
commitablectx.markcommitted() in the next patchbomb. We can always clean it
up later if it is wrong.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] commitextras: move fb's extension which add extras to a commit to core

[Kevin Bullock]

> On Jul 7, 2017, at 13:25, Martin von Zweigbergk via Mercurial-devel 
>  wrote:
> 
> On Fri, Jul 7, 2017 at 11:23 AM, Sean Farley  wrote:
>> 
>> Yuya Nishihara  writes:
>>> 
>>> debugcommit seems fine.
>>> 
>>> FWIW, --extra value will need some encoding handling depending on its
>>> type, e.g. convert labels to utf-8, but keep file path as bytes.
>> 
>> Yeah, seems fine to me too. But was there any reason we're avoiding the
>> path of new-thing-as-extension first, then into core second?
> 
> If we decide to put it in debugcommit, we provide no BC guarantee
> (AFAIK), so we can remove it later if we see a reason. That buys us
> the same flexibility as having it in an extensions, it seems.

Hmm, I'm not sure we throw out BC guarantees for debug commands. Per 
, there is 
somewhat of a gradient to the strength of BC guarantees, but as I read it, 
debug commands aren't exempt.

Also just as a reminder for those following along, we only suspend the BC 
guarantees for extensions that are marked EXPERIMENTAL.

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] commitextras: move fb's extension which add extras to a commit to core

[Kevin Bullock]

> On Jul 7, 2017, at 13:23, Sean Farley  wrote:
> 
> Yuya Nishihara  writes:
> 
>> debugcommit seems fine.
>> 
>> FWIW, --extra value will need some encoding handling depending on its
>> type, e.g. convert labels to utf-8, but keep file path as bytes.
> 
> Yeah, seems fine to me too. But was there any reason we're avoiding the
> path of new-thing-as-extension first, then into core second?

I don't think we're explicitly avoiding that. It could very well come in as an 
extension that adds the debugcommit command.

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] commitextras: move fb's extension which add extras to a commit to core

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 11:23 AM, Sean Farley  wrote:
>
> Yuya Nishihara  writes:
>
>> On Thu, 6 Jul 2017 14:24:08 -0700, Martin von Zweigbergk wrote:
>>> On Thu, Jul 6, 2017 at 10:58 AM, Sean Farley  wrote:
>>> > Yuya Nishihara  writes:
>>> >> On Wed, 05 Jul 2017 23:14:13 +0530, Pulkit Goyal wrote:
>>> >>> # HG changeset patch
>>> >>> # User Pulkit Goyal <7895pul...@gmail.com>
>>> >>> # Date 1499274297 -19800
>>> >>> #  Wed Jul 05 22:34:57 2017 +0530
>>> >>> # Node ID 64c39cf4b61475a133f88fa6dd247ca4f3d61436
>>> >>> # Parent  8e6f4939a69ae8949e134d97de6b766799bca8de
>>> >>> # EXP-Topic fbext
>>> >>> commitextras: move fb's extension which add extras to a commit to core
>>> >>>
>>> >>> Facebook has this as extension which adds a flag to `hg commit` to add 
>>> >>> extra
>>> >>> values to a commit from command line. This patch moves that extension 
>>> >>> to core by
>>> >>> adding that flag and marking that as ADVANCED. Also this patch adds a 
>>> >>> function
>>> >>> to check if any key which is used internally can't be used.
>>> >>
>>> >> FYI, the last attempt was rejected.
>>> >>
>>> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2014-March/056889.html
>>> >
>>> > Ha, I was going to dig that message up as well.
>>> >
>>> >> I don't know if ADVANCED flag can make the "high barrier" enough to 
>>> >> discourage
>>> >> an abuse of extras.
>>> >
>>> > I agree with this and with Matt's original criticism. Can this not be an
>>> > extension instead?
>>>
>>> How about make a debugcommit command that adds this flag and delegates
>>> everything else to the regular commit command?
>>
>> debugcommit seems fine.
>>
>> FWIW, --extra value will need some encoding handling depending on its
>> type, e.g. convert labels to utf-8, but keep file path as bytes.
>
> Yeah, seems fine to me too. But was there any reason we're avoiding the
> path of new-thing-as-extension first, then into core second?

If we decide to put it in debugcommit, we provide no BC guarantee
(AFAIK), so we can remove it later if we see a reason. That buys us
the same flexibility as having it in an extensions, it seems.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] commitextras: move fb's extension which add extras to a commit to core

[Sean Farley]

Yuya Nishihara  writes:

> On Thu, 6 Jul 2017 14:24:08 -0700, Martin von Zweigbergk wrote:
>> On Thu, Jul 6, 2017 at 10:58 AM, Sean Farley  wrote:
>> > Yuya Nishihara  writes:
>> >> On Wed, 05 Jul 2017 23:14:13 +0530, Pulkit Goyal wrote:
>> >>> # HG changeset patch
>> >>> # User Pulkit Goyal <7895pul...@gmail.com>
>> >>> # Date 1499274297 -19800
>> >>> #  Wed Jul 05 22:34:57 2017 +0530
>> >>> # Node ID 64c39cf4b61475a133f88fa6dd247ca4f3d61436
>> >>> # Parent  8e6f4939a69ae8949e134d97de6b766799bca8de
>> >>> # EXP-Topic fbext
>> >>> commitextras: move fb's extension which add extras to a commit to core
>> >>>
>> >>> Facebook has this as extension which adds a flag to `hg commit` to add 
>> >>> extra
>> >>> values to a commit from command line. This patch moves that extension to 
>> >>> core by
>> >>> adding that flag and marking that as ADVANCED. Also this patch adds a 
>> >>> function
>> >>> to check if any key which is used internally can't be used.
>> >>
>> >> FYI, the last attempt was rejected.
>> >>
>> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2014-March/056889.html
>> >
>> > Ha, I was going to dig that message up as well.
>> >
>> >> I don't know if ADVANCED flag can make the "high barrier" enough to 
>> >> discourage
>> >> an abuse of extras.
>> >
>> > I agree with this and with Matt's original criticism. Can this not be an
>> > extension instead?
>> 
>> How about make a debugcommit command that adds this flag and delegates
>> everything else to the regular commit command?
>
> debugcommit seems fine.
>
> FWIW, --extra value will need some encoding handling depending on its
> type, e.g. convert labels to utf-8, but keep file path as bytes.

Yeah, seems fine to me too. But was there any reason we're avoiding the
path of new-thing-as-extension first, then into core second?


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

Re: [PATCH 5 of 5] template: add successors template

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-07-07 10:39:55 -0700:
> Boris described it as "closest successors", so maybe "closestsuccessors"?

Maybe a bit off-topic, but I have been thinking about "predecessors" and
"successors" revsets for a while. It sounds like we could have many
combinations so I was thinking about keyword arguments, like:

successors(REV, all=False, closest=False)

For example, with two markers: A -> (B, C), B -> (D),

successors(A) = [C, D]
successors(A, all=True) = [B, C, D]
successors(A, closest=True) = [C] (without --hidden)
  [B, C] (with --hidden)

Also check my comment on Yuya's revset change [1].

I wonder if we can just implement the revsets, and because there is a
"revset" template function, template gets those features for free.

[1]: 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-July/101140.html
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revset: add experimental set subscript operator

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-07-08 01:11:50 +0900:
> Just a nitpick. They are quite different operations if we take the #op
> as an order specifier.
> 
>  x[y] (indexing) selects the y-th element from x (inside x)
>  x{y} goes to the y-th elements from x (outside x)
> 
> But, ...

Good catch. Then it makes sense to use different operators.

I wonder if we have some real world examples of "y-th element from x". I
couldn't really think of good convincing examples so it might be an
operation we don't provide intentionally.

> We could read 'x#op' as 'x->op()' in C++, so 'x#changelog' could be considered
> 'ancestors(x) + descendants(x)' operation with depth index.
>
> Perhaps, a drawback of this idea is that the syntax is verbose, and parsing
> will be a bit complex.

Maybe allow them to be shorter, like "#c", "#l", "#o". Then it is only one
character longer than "[1c]", "[1l]", "[1o]". I think the latter also looks
good. The key difference would be whether we want "[]" to be like existing
language or not.

Slightly off-topic, I wonder if we can make "#o", "#l" or "#c" without "[]"
something useful, like "hg log -r 'x#o'" could imply "using the obsolete
graph, "hg log -rf 'x#l'" means "using the linear graph". It feels like an
extra bit of information similar to "istopo". I have been thinking about
"log --dag DAGTYPE". This might be a way to embed the flag into revset, just
like other log flags.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 5] template: add successors template

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Jul 7, 2017 at 10:29 AM, Jun Wu  wrote:
> Excerpts from Sean Farley's message of 2017-07-06 11:05:22 -0700:
>> Augie Fackler  writes:
>> > On Wed, Jul 05, 2017 at 10:53:58PM +0200, Boris Feld wrote:
>> > I'm not...super in love with the name successorssets, but I have no
>> > better ideas. I'd welcome some bikeshedding in the next ten days.
>>
>> Off the top of my head:
>>
>> successorgroup
>> successorlike
>> similarsuccessors
>> successorkin
>
> "group" looks better to me than "similar". "similar" sounds like there is
> some filtering logic that removes non-similar ones.
>
> "successorsset" looks okay to me, since "set" and "group" are not that much
> different.

Boris described it as "closest successors", so maybe "closestsuccessors"?

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

Re: [PATCH 5 of 5] template: add successors template

[Jun Wu]

Excerpts from Sean Farley's message of 2017-07-06 11:05:22 -0700:
> Augie Fackler  writes:
> > On Wed, Jul 05, 2017 at 10:53:58PM +0200, Boris Feld wrote:
> > I'm not...super in love with the name successorssets, but I have no
> > better ideas. I'd welcome some bikeshedding in the next ten days.
> 
> Off the top of my head:
> 
> successorgroup
> successorlike
> similarsuccessors
> successorkin

"group" looks better to me than "similar". "similar" sounds like there is
some filtering logic that removes non-similar ones.

"successorsset" looks okay to me, since "set" and "group" are not that much
different.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] releasenotes: add custom admonitions support for release notes

[Rishabh Madan]

Sorry, I forgot to put the v2 flag.
ᐧ

On Fri, Jul 7, 2017 at 7:13 PM, Rishabh Madan 
wrote:

> # HG changeset patch
> # User Rishabh Madan 
> # Date 1499447586 -7200
> #  Fri Jul 07 19:13:06 2017 +0200
> # Node ID 766932e4c2768577173f1bfaa10e919b9df739ec
> # Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
> releasenotes: add custom admonitions support for release notes
>
> By default, the extension has default sections like fix, feature, perf
> etc.. This
> patch allow user to add support for custom admonition. In order to add a
> custom
> admonition, one needs to have a .hgadmonitions file inside the repository.
> All the
> custom directive with name specified under the tag [releasenotes.sections]
> will be
> usable by the extension. One important thing to keep in mind is if there
> exists any
> custom admonitions then they will override the default ones.
>
> diff -r e714159860fd -r 766932e4c276 hgext/releasenotes.py
> --- a/hgext/releasenotes.py Fri Jul 07 08:33:10 2017 +0200
> +++ b/hgext/releasenotes.py Fri Jul 07 19:13:06 2017 +0200
> @@ -20,6 +20,7 @@
>
>  from mercurial.i18n import _
>  from mercurial import (
> +config,
>  error,
>  minirst,
>  registrar,
> @@ -111,9 +112,12 @@
>  self.addnontitleditem(section, paragraphs)
>
>  class releasenotessections(object):
> -def __init__(self, ui):
> -# TODO support defining custom sections from config.
> -self._sections = list(DEFAULT_SECTIONS)
> +def __init__(self, repo, revs, ui):
> +custom_sections = self.getcustomadmonitions(repo, revs, ui)
> +if custom_sections:
> +self._sections = custom_sections
> +else:
> +self._sections = list(DEFAULT_SECTIONS) + custom_sections
>
>  def __iter__(self):
>  return iter(self._sections)
> @@ -128,6 +132,38 @@
>
>  return None
>
> +def getcustomadmonitions(self, repo, revs, ui):
> +custom_sections = list()
> +for rev in revs:
> +ctx = repo[rev]
> +p = config.config()
> +repo = ctx.repo()
> +
> +def read(f, sections=None, remap=None):
> +if f in ctx:
> +try:
> +data = ctx[f].data()
> +
> +except IOError as err:
> +if err.errno != errno.ENOENT:
> +raise
> +ui.warn(_("warning: .hgadmonitions file \'%s\' not
> found\n") %
> +repo.pathto(f))
> +return
> +p.parse(f, data, sections, remap, read)
> +sectiondict = p.__getitem__(sections)
> +sectionlist = list()
> +for key, value in sectiondict.iteritems():
> +temp = (key, value)
> +sectionlist.append(temp)
> +else:
> +raise error.Abort(_(".hgadmonitions file \'%s\' not
> found") %
> +  repo.pathto(f))
> +return sectionlist
> +if '.hgadmonitions' in ctx:
> +custom_sections = read('.hgadmonitions',
> 'releasenotes.sections')
> +return custom_sections
> +
>  def parsenotesfromrevisions(repo, directives, revs):
>  notes = parsedreleasenotes()
>
> @@ -396,9 +432,9 @@
>  that file. A particular use case for this is to tweak the wording of a
>  release note after it has been added to the release notes file.
>  """
> -sections = releasenotessections(ui)
> +revs = scmutil.revrange(repo, [rev or 'not public()'])
>
> -revs = scmutil.revrange(repo, [rev or 'not public()'])
> +sections = releasenotessections(repo, revs, ui)
>  incoming = parsenotesfromrevisions(repo, sections.names(), revs)
>
>  try:
> @@ -411,7 +447,7 @@
>  notes = parsedreleasenotes()
>
>  notes.merge(ui, incoming)
> -
> +print(incoming)
>  with open(file_, 'wb') as fh:
>  fh.write(serializenotes(sections, notes))
>
>


-- 
Rishabh Madan
Second Year Undergraduate student
Indian Institute of Technology, Kharagpur
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] releasenotes: add custom admonitions support for release notes

[Rishabh Madan]

# HG changeset patch
# User Rishabh Madan 
# Date 1499447586 -7200
#  Fri Jul 07 19:13:06 2017 +0200
# Node ID 766932e4c2768577173f1bfaa10e919b9df739ec
# Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
releasenotes: add custom admonitions support for release notes

By default, the extension has default sections like fix, feature, perf etc.. 
This
patch allow user to add support for custom admonition. In order to add a custom
admonition, one needs to have a .hgadmonitions file inside the repository. All 
the
custom directive with name specified under the tag [releasenotes.sections] will 
be
usable by the extension. One important thing to keep in mind is if there exists 
any
custom admonitions then they will override the default ones.

diff -r e714159860fd -r 766932e4c276 hgext/releasenotes.py
--- a/hgext/releasenotes.py Fri Jul 07 08:33:10 2017 +0200
+++ b/hgext/releasenotes.py Fri Jul 07 19:13:06 2017 +0200
@@ -20,6 +20,7 @@
 
 from mercurial.i18n import _
 from mercurial import (
+config,
 error,
 minirst,
 registrar,
@@ -111,9 +112,12 @@
 self.addnontitleditem(section, paragraphs)
 
 class releasenotessections(object):
-def __init__(self, ui):
-# TODO support defining custom sections from config.
-self._sections = list(DEFAULT_SECTIONS)
+def __init__(self, repo, revs, ui):
+custom_sections = self.getcustomadmonitions(repo, revs, ui)
+if custom_sections:
+self._sections = custom_sections
+else:
+self._sections = list(DEFAULT_SECTIONS) + custom_sections
 
 def __iter__(self):
 return iter(self._sections)
@@ -128,6 +132,38 @@
 
 return None
 
+def getcustomadmonitions(self, repo, revs, ui):
+custom_sections = list()
+for rev in revs:
+ctx = repo[rev]
+p = config.config()
+repo = ctx.repo()
+
+def read(f, sections=None, remap=None):
+if f in ctx:
+try:
+data = ctx[f].data()
+
+except IOError as err:
+if err.errno != errno.ENOENT:
+raise
+ui.warn(_("warning: .hgadmonitions file \'%s\' not 
found\n") %
+repo.pathto(f))
+return
+p.parse(f, data, sections, remap, read)
+sectiondict = p.__getitem__(sections)
+sectionlist = list()
+for key, value in sectiondict.iteritems():
+temp = (key, value)
+sectionlist.append(temp)
+else:
+raise error.Abort(_(".hgadmonitions file \'%s\' not found") %
+  repo.pathto(f))
+return sectionlist
+if '.hgadmonitions' in ctx:
+custom_sections = read('.hgadmonitions', 'releasenotes.sections')
+return custom_sections
+
 def parsenotesfromrevisions(repo, directives, revs):
 notes = parsedreleasenotes()
 
@@ -396,9 +432,9 @@
 that file. A particular use case for this is to tweak the wording of a
 release note after it has been added to the release notes file.
 """
-sections = releasenotessections(ui)
+revs = scmutil.revrange(repo, [rev or 'not public()'])
 
-revs = scmutil.revrange(repo, [rev or 'not public()'])
+sections = releasenotessections(repo, revs, ui)
 incoming = parsenotesfromrevisions(repo, sections.names(), revs)
 
 try:
@@ -411,7 +447,7 @@
 notes = parsedreleasenotes()
 
 notes.merge(ui, incoming)
-
+print(incoming)
 with open(file_, 'wb') as fh:
 fh.write(serializenotes(sections, notes))
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 12 of 14] vfs: add the possibility to have a "ward" to check vfs usage

[Boris Feld]

On Fri, 2017-07-07 at 21:48 +0900, Yuya Nishihara wrote:
> On Thu, 06 Jul 2017 20:53:50 +0200, Boris Feld wrote:
> > On Wed, 2017-07-05 at 23:55 +0900, Yuya Nishihara wrote:
> > > On Sun, 02 Jul 2017 04:56:37 +0200, Pierre-Yves David wrote:
> > > > # HG changeset patch
> > > > # User Pierre-Yves David 
> > > > # Date 1470323266 -7200
> > > > #  Thu Aug 04 17:07:46 2016 +0200
> > > > # Node ID ebf81efdd6d7ff15c64683933635616c00475688
> > > > # Parent  34b8be7f0420b07d0f7b71379c6055e5b26223d5
> > > > # EXP-Topic vfs.ward
> > > > # Available At https://www.mercurial-scm.org/repo/users/marmout
> > > > e/me
> > > > rcurial/
> > > > #  hg pull https://www.mercurial-scm.org/repo/users
> > > > /mar
> > > > moute/mercurial/ -r ebf81efdd6d7
> > > > vfs: add the possibility to have a "ward" to check vfs usage
> > > > The feature has some similarity with the 'pathauditor', but
> > > > further
> > > > digging
> > > > show it make more sense to keep them separated. The path
> > > > auditor is
> > > > fairly
> > > > autonomous (create from vfs.__init__ without any extra
> > > > information), and check
> > > > very generic details. On the other hand, the wards will have
> > > > deeper
> > > > knownledge
> > > > of the Mercurial logic and is created at the local repository
> > > > level. Mixing the
> > > > two would add much complexity for no real gains.
> > > 
> > > My gut feeling is that vfs isn't the right place if they require
> > > deeper
> > > knowledge of repository/dirstate logic. And the whole weakref
> > > business
> > > floating around wards, hooks and transaction seems like just
> > > getting
> > > around
> > > layering violation.
> > 
> > We pondered on this choice a long time and couldn't find any other
> > layer that is used by both Mercurial core and the extensions to
> > access
> > the file system. It seems to be the highest abstraction layer we
> > could
> > hook into without introducing a new one and updating all callers.
> > 
> > Our reflexion is, as the vfs classes comes from the scmutil file,
> > it
> > seems okay to have scm related logic in that layer.
> 
> IIRC, one possible alternative was to move lock itself to a vfs as
> the
> whole vfs is theoretically covered by the lock.

The practice divert a bit from the theory. For example, the
".hg/bookmark" file is in theory covered by the 'wlock'. In practice it
is now covered by the transaction and therefor the 'lock'. On the other
hand there are multiple files handled by the vfs ('hgrc', 'dirstate',
'store/', etc) that are not covered by the wlock.

Right now, all these exceptions are stored on the repository, and
extension can update them. To us, the repository layers seems the right
layer for logic regarding individual file semantic. We also want to add
some logic regarding open transaction to the ward, something unrelated
to the vfs.

The initial motivation for this series (beside catching bug) is to make
it safer to introduce new vfs. For example, the share extensions
suffers from lack of cache sharing, each share has its own '.hg/cache/'
directory. Introducing a 'repo.cvfs' dedicated to cache could fix that,
but we wants to warn people still accessing 'cache/' through
'repo.vfs'.

To push that logic further, "share" actually needs a better distinction
between the working copy specific piece and the more generic pieces. An
extra split of "repo.vfs" could take care of that. However, some of the
file, like bookmark, can be shared or not depending on some config and
share option. So the ward needs access to that logic (already living on
the repository) too.

We need to eventually rework the repository format to a more race free
data structure. This will likely involve more vfs to access data
dispatched in various directory (eg: append-only vs full update). The
ward should help a lot here but it need to be aware of many high level
logic regarding file semantic.

We plan to add more vfs-s and the current locking design seems better
than having one lock per vfs, as multiple vfs will be covered by the
same lock. If we move the locks on the vfs layer, we either would need
to update it again later or introduce much more complex code to manage
the interaction between vfs-s locks.

> 
> BTW, the ward itself doesn't require deeper knowledge of repo object
> right
> now. Neither does the auditor. How will the ward API be evolved to
> depend
> on repository-level data?

In this series, the vfs ward use data from "repo._wlockfreeprefix" to
read its exception. Given the type of data and the need for extension
to wrap it. The repo seems a good place to hold this data.

> 
> > > Do you have any idea how to expand this ward() callback to the
> > > other
> > > vfs
> > > operations, which have different set of parameters?
> > 
> > All other operations (move, delete, copy, etc) could be
> > "translated" to
> > 'read' or 'write' mode. An alternative would be to abstract the
> > mode
> > with a couple of symbolic constant 

Re: [PATCH 5 of 5] template: add successors template

[Sean Farley]

Yuya Nishihara  writes:

> On Thu, 06 Jul 2017 11:05:22 -0700, Sean Farley wrote:
>> Augie Fackler  writes:
>> > On Wed, Jul 05, 2017 at 10:53:58PM +0200, Boris Feld wrote:
>> >> # HG changeset patch
>> >> # User Boris Feld 
>> >> # Date 1499073720 -7200
>> >> #  Mon Jul 03 11:22:00 2017 +0200
>> >> # Node ID 82e2b4eb96b573dde890d725d758dbbc49407133
>> >> # Parent  870bfaafd90e030b85b869922050be98f000a9a9
>> >> # EXP-Topic successorstemplate
>> >> template: add successors template
>> >
>> > queued, thanks
>> >
>> >>
>> >> Add a 'successorssets' template that returns the list of all closest known
>> >> sucessorssets for a changectx. The elements of the list are changesets.
>> >
>> > I'm not...super in love with the name successorssets, but I have no
>> > better ideas. I'd welcome some bikeshedding in the next ten days.
>> 
>> Off the top of my head:
>> 
>> successorgroup
>> successorlike
>> similarsuccessors
>> successorkin
>
> No idea which is better, but a name like "similarsuccessors" might be nice
> to justify calling the inner list as "successors".
>
>   {similarsuccessors % "{successors % ...}"}
>  ^^
>   sounds okay, and its actually a partial list of successors
>
>   {successorgroup % "{group % ...}"}
>   ^
>   calling it "successors" seems a bit odd because "group" is noun

I like similarsuccessors, fwiw. Also, "successors" is a noun as well.


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

Re: [PATCH] revset: add experimental set subscript operator

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2017-07-07 21:25:17 +0900:
> On Thu, 06 Jul 2017 19:04:48 -0700, Sean Farley wrote:
> > Jun Wu  writes:
> > > Could it be foo[+4][1] meaning what you want? An explicit "+" means
> > > it's an offset, the "1" without a "+" means it's a normal index.
> > 
> > Hmmm, I'll have to mull on that. My gut feeling is that it might be too
> > magical. Though, we're severely limited on characters so it might be the
> > least-worst option.
> 
> It's confusing. You might think foo[-1] will return the last element in
> foo.
> 
> If we don't want to use {} but also want to reserve [] for future use,
> we'll need a completely different operator, e.g. foo[[4]], foo~[4]
> foo#[4].

Think it a bit more, they look similar: given some order information (a
list, changelog DAG, or obsolete graph), do indexing, or slicing.

It seems the missing bit here is to specify which "order" to use. Suppose
the operator is "[]", that "order" information may be provided inside the
operator ("[1o]", "[-2g]", like what mpm said), or at the operator itself
(use different operators), or outside the operator.

Inside operator may create some syntax inconsistent with other languages.
Different operators may exhaust our operators.

I'm currently leaning towards "outside the operator". That could make "[]"
closer to existing language. It also looks flexible and clean.  For example,
use "#ordertype", like:

  x#changelog[3]:  x~-3 (approximately)
  x#changelog[-3]: x~3 (approximately)
  x#changelog[0:3]: x + x~-1 + x~-2 + x~-3
  x#changelog[1:]: descendants(x) - x

  x#changeloglinear[-3]: x~3 (only consider p1 to make history linear)
  x#changeloglinear[:0]: _firstancestors(x)

  x#obsolete[1]: successors(x)
  x#obsolete[1:]: allsuccessors(x) - x 
  x#obsolete[:]: allprecursors(x) + allsuccessors(x)

  x#plainlist[1]: pick the second element in the list
  x#plainlist[-1]: pick the last element in the list
  x#plainlist[1:3]: pick a slice in the list

We can specify a default order, like "#changelog" or "#plainlist".

Note: the names (changeloglinear etc.) here are just examples, not final.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@33329: 46 new changesets

[Mercurial Commits]

46 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/b2670290eab4
changeset:   33284:b2670290eab4
user:Denis Laxalde 
date:Wed Jul 05 13:54:53 2017 +0200
summary: followlines: join merge parents line ranges in blockdescendants() 
(issue5595)

https://www.mercurial-scm.org/repo/hg/rev/98f6c25aaf61
changeset:   33285:98f6c25aaf61
user:Augie Fackler 
date:Tue Jun 20 17:25:57 2017 -0400
summary: contrib: widen the "don't use `python`" net a little

https://www.mercurial-scm.org/repo/hg/rev/2428e8ec0793
changeset:   33286:2428e8ec0793
user:Augie Fackler 
date:Tue Jun 20 17:31:18 2017 -0400
summary: tests: clean up even more direct `python` calls with $PYTHON

https://www.mercurial-scm.org/repo/hg/rev/e26a3adc8f5c
changeset:   33287:e26a3adc8f5c
user:Kevin Bullock 
date:Thu Jul 06 14:33:48 2017 -0500
summary: tests: clean up a newly-introduced instance of `python`

https://www.mercurial-scm.org/repo/hg/rev/f08a178adadf
changeset:   33288:f08a178adadf
user:Augie Fackler 
date:Thu Jul 06 15:15:02 2017 -0400
summary: contrib: widen "direct use of `python`" net again

https://www.mercurial-scm.org/repo/hg/rev/abd7dedbaa36
changeset:   33289:abd7dedbaa36
user:Gregory Szorc 
date:Sat Jul 01 10:43:29 2017 -0700
summary: sparse: vendor Facebook-developed extension

https://www.mercurial-scm.org/repo/hg/rev/cd1c275c9482
changeset:   33290:cd1c275c9482
user:Gregory Szorc 
date:Sat Jul 01 10:36:03 2017 -0700
summary: sparse: expand module docstring

https://www.mercurial-scm.org/repo/hg/rev/74923cec6fdb
changeset:   33291:74923cec6fdb
user:Gregory Szorc 
date:Sat Jul 01 10:24:31 2017 -0700
summary: sparse: remove reference to hgwatchman

https://www.mercurial-scm.org/repo/hg/rev/1e9fd2c35ae3
changeset:   33292:1e9fd2c35ae3
user:Gregory Szorc 
date:Thu Jul 06 10:54:23 2017 -0700
summary: sparse: remove reference to simplecache

https://www.mercurial-scm.org/repo/hg/rev/c9cbf4de27ba
changeset:   33293:c9cbf4de27ba
user:Gregory Szorc 
date:Sat Jul 01 10:29:27 2017 -0700
summary: sparse: rename command to debugsparse

https://www.mercurial-scm.org/repo/hg/rev/a5921ad2eb99
changeset:   33294:a5921ad2eb99
user:Gregory Szorc 
date:Thu Jul 06 10:57:26 2017 -0700
summary: sparse: document config file format

https://www.mercurial-scm.org/repo/hg/rev/c72e9c61d2b1
changeset:   33295:c72e9c61d2b1
user:Gregory Szorc 
date:Sat Jul 01 11:56:39 2017 -0700
summary: sparse: refactor sparsechecksum()

https://www.mercurial-scm.org/repo/hg/rev/ee616196227c
changeset:   33296:ee616196227c
user:Gregory Szorc 
date:Thu Jul 06 10:58:45 2017 -0700
summary: sparse: use vfs.tryread()

https://www.mercurial-scm.org/repo/hg/rev/ba5d89774db6
changeset:   33297:ba5d89774db6
user:Gregory Szorc 
date:Thu Jul 06 12:14:03 2017 -0700
summary: sparse: move config parsing into core

https://www.mercurial-scm.org/repo/hg/rev/f41a99c45956
changeset:   33298:f41a99c45956
user:Gregory Szorc 
date:Thu Jul 06 12:14:12 2017 -0700
summary: sparse: move profile reading into core

https://www.mercurial-scm.org/repo/hg/rev/41448fc51510
changeset:   33299:41448fc51510
user:Gregory Szorc 
date:Thu Jul 06 12:06:37 2017 -0700
summary: sparse: variable to track if sparse is enabled

https://www.mercurial-scm.org/repo/hg/rev/f7a106b3f089
changeset:   33300:f7a106b3f089
user:Gregory Szorc 
date:Thu Jul 06 12:15:14 2017 -0700
summary: sparse: move resolving of sparse patterns for rev into core

https://www.mercurial-scm.org/repo/hg/rev/ca4b78eb11e7
changeset:   33301:ca4b78eb11e7
user:Gregory Szorc 
date:Thu Jul 06 12:26:04 2017 -0700
summary: sparse: move active profiles function into core

https://www.mercurial-scm.org/repo/hg/rev/36a415b5a4b2
changeset:   33302:36a415b5a4b2
user:Gregory Szorc 
date:Thu Jul 06 12:20:53 2017 -0700
summary: localrepo: add sparse caches

https://www.mercurial-scm.org/repo/hg/rev/8b571495d811
changeset:   33303:8b571495d811
user:Gregory Szorc 
date:Thu Jul 06 12:24:55 2017 -0700
summary: sparse: move config file writing into core

https://www.mercurial-scm.org/repo/hg/rev/3e1accab7447
changeset:   33304:3e1accab7447
user:Gregory Szorc 

[PATCH 3 of 3] vfs: rename auditvfs to proxyvfs

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1499438400 -32400
#  Fri Jul 07 23:40:00 2017 +0900
# Node ID a10abcecbd75a060cabea857458b7c921704cb4b
# Parent  4249fe0f2a768bd556bd8e69e1b62baa20594190
vfs: rename auditvfs to proxyvfs

Since we've removed mustaudit property, auditvfs has no auditing business.
It's just a utility class for vfs wrappers.

diff --git a/mercurial/store.py b/mercurial/store.py
--- a/mercurial/store.py
+++ b/mercurial/store.py
@@ -475,9 +475,9 @@ class fncache(object):
 self._load()
 return iter(self.entries)
 
-class _fncachevfs(vfsmod.abstractvfs, vfsmod.auditvfs):
+class _fncachevfs(vfsmod.abstractvfs, vfsmod.proxyvfs):
 def __init__(self, vfs, fnc, encode):
-vfsmod.auditvfs.__init__(self, vfs)
+vfsmod.proxyvfs.__init__(self, vfs)
 self.fncache = fnc
 self.encode = encode
 
diff --git a/mercurial/vfs.py b/mercurial/vfs.py
--- a/mercurial/vfs.py
+++ b/mercurial/vfs.py
@@ -441,7 +441,7 @@ class vfs(abstractvfs):
 
 opener = vfs
 
-class auditvfs(object):
+class proxyvfs(object):
 def __init__(self, vfs):
 self.vfs = vfs
 
@@ -453,11 +453,11 @@ class auditvfs(object):
 def options(self, value):
 self.vfs.options = value
 
-class filtervfs(abstractvfs, auditvfs):
+class filtervfs(abstractvfs, proxyvfs):
 '''Wrapper vfs for filtering filenames with a function.'''
 
 def __init__(self, vfs, filter):
-auditvfs.__init__(self, vfs)
+proxyvfs.__init__(self, vfs)
 self._filter = filter
 
 def __call__(self, path, *args, **kwargs):
@@ -471,11 +471,11 @@ class filtervfs(abstractvfs, auditvfs):
 
 filteropener = filtervfs
 
-class readonlyvfs(abstractvfs, auditvfs):
+class readonlyvfs(abstractvfs, proxyvfs):
 '''Wrapper vfs preventing any writing.'''
 
 def __init__(self, vfs):
-auditvfs.__init__(self, vfs)
+proxyvfs.__init__(self, vfs)
 
 def __call__(self, path, mode='r', *args, **kw):
 if mode not in ('r', 'rb'):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] summary: fix type of empty unresolved list

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1499436784 -32400
#  Fri Jul 07 23:13:04 2017 +0900
# Node ID de50a2f8fd984912893b6aea79cd0d7ab0b83299
# Parent  e714159860fd0872ae0555bb07546aa7e9f700e0
summary: fix type of empty unresolved list

It was okay because tested as a boolean prior to calling len(), but looked
incorrect.

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -4774,7 +4774,7 @@ def summary(ui, repo, **opts):
 s = ' '.join(e.recordtypes)
 ui.warn(
 _('warning: merge state has unsupported record types: %s\n') % s)
-unresolved = 0
+unresolved = []
 else:
 unresolved = list(ms.unresolved())
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 3] streamclone: close large revlog files explicitly in generatev1()

[Yuya Nishihara]

# HG changeset patch
# User Yuya Nishihara 
# Date 1499437516 -32400
#  Fri Jul 07 23:25:16 2017 +0900
# Node ID 975c99e7fc675b5f1f89b348cc91651e0d48eb61
# Parent  de50a2f8fd984912893b6aea79cd0d7ab0b83299
streamclone: close large revlog files explicitly in generatev1()

diff --git a/mercurial/streamclone.py b/mercurial/streamclone.py
--- a/mercurial/streamclone.py
+++ b/mercurial/streamclone.py
@@ -221,13 +221,12 @@ def generatev1(repo):
 repo.ui.debug('sending %s (%d bytes)\n' % (name, size))
 # partially encode name over the wire for backwards compat
 yield '%s\0%d\n' % (store.encodedir(name), size)
-if size <= 65536:
-with svfs(name, 'rb', auditpath=False) as fp:
+with svfs(name, 'rb', auditpath=False) as fp:
+if size <= 65536:
 yield fp.read(size)
-else:
-data = svfs(name, auditpath=False)
-for chunk in util.filechunkiter(data, limit=size):
-yield chunk
+else:
+for chunk in util.filechunkiter(fp, limit=size):
+yield chunk
 
 return len(entries), total_bytes, emitrevlogdata()
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] dispatch: fix typo suggestion for disabled extension

[Yuya Nishihara]

On Fri, 07 Jul 2017 00:26:16 -0700, Martin von Zweigbergk via Mercurial-devel 
wrote:
> # HG changeset patch
> # User Martin von Zweigbergk 
> # Date 1499411633 25200
> #  Fri Jul 07 00:13:53 2017 -0700
> # Node ID f968eaa9c1e45e19a90423d875d1538ebb30d884
> # Parent  46c6014cd9765a04b61fe03b907f9eceaabba0dd
> dispatch: fix typo suggestion for disabled extension

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 v4] configitems: add alias support in config

[Yuya Nishihara]

On Fri, 07 Jul 2017 08:37:32 +0200, David Demelier wrote:
> # HG changeset patch
> # User David Demelier 
> # Date 1499409190 -7200
> #  Fri Jul 07 08:33:10 2017 +0200
> # Node ID 936ce124293ab334d10239c9088c74f47fc55212
> # Parent  d32ff523e0219b48b119d9dc44d9d07638153a72
> configitems: add alias support in config

Queued, many thanks.

>  def _config(self, section, name, default=_unset, untrusted=False):
>  value = default
> -if isinstance(name, list):
> -alternates = name
> -else:
> -item = self._knownconfig.get(section, {}).get(name)
> -if default is _unset:
> -if item is None:
> -value = default
> -elif callable(item.default):
> +item = self._knownconfig.get(section, {}).get(name)
> +alternates = [(section, name)]
> +
> +if item is not None:
> +alternates.extend(item.alias)
> +
> +if default is _unset:
> +if item is None:
> +value = default
> +elif callable(item.default):
>  value = item.default()
> -else:
> -value = item.default
> -elif item is not None:
> -msg = ("specifying a default value for a registered "
> -   "config item: '%s.%s' '%s'")
> -msg %= (section, name, default)
> -self.develwarn(msg, 2, 'warn-config-default')
> +else:
> +value = item.default
> +elif item is not None:
> +msg = ("specifying a default value for a registered "
> +   "config item: '%s.%s' '%s'")
> +msg %= (section, name, default)
> +self.develwarn(msg, 2, 'warn-config-default')
>  
> -alternates = [name]
> -
> -for n in alternates:
> -candidate = self._data(untrusted).get(section, n, None)
> +for s, n in alternates:
> +candidate = self._data(untrusted).get(s, n, None)
>  if candidate is not None:
>  value = candidate
> +section = s
>  name = n
>  break

Nit: section and name set here appear to be unused.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 5] template: add successors template

[Yuya Nishihara]

On Thu, 06 Jul 2017 11:05:22 -0700, Sean Farley wrote:
> Augie Fackler  writes:
> > On Wed, Jul 05, 2017 at 10:53:58PM +0200, Boris Feld wrote:
> >> # HG changeset patch
> >> # User Boris Feld 
> >> # Date 1499073720 -7200
> >> #  Mon Jul 03 11:22:00 2017 +0200
> >> # Node ID 82e2b4eb96b573dde890d725d758dbbc49407133
> >> # Parent  870bfaafd90e030b85b869922050be98f000a9a9
> >> # EXP-Topic successorstemplate
> >> template: add successors template
> >
> > queued, thanks
> >
> >>
> >> Add a 'successorssets' template that returns the list of all closest known
> >> sucessorssets for a changectx. The elements of the list are changesets.
> >
> > I'm not...super in love with the name successorssets, but I have no
> > better ideas. I'd welcome some bikeshedding in the next ten days.
> 
> Off the top of my head:
> 
> successorgroup
> successorlike
> similarsuccessors
> successorkin

No idea which is better, but a name like "similarsuccessors" might be nice
to justify calling the inner list as "successors".

  {similarsuccessors % "{successors % ...}"}
 ^^
  sounds okay, and its actually a partial list of successors

  {successorgroup % "{group % ...}"}
  ^
  calling it "successors" seems a bit odd because "group" is noun
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] commitextras: move fb's extension which add extras to a commit to core

[Yuya Nishihara]

On Thu, 6 Jul 2017 14:24:08 -0700, Martin von Zweigbergk wrote:
> On Thu, Jul 6, 2017 at 10:58 AM, Sean Farley  wrote:
> > Yuya Nishihara  writes:
> >> On Wed, 05 Jul 2017 23:14:13 +0530, Pulkit Goyal wrote:
> >>> # HG changeset patch
> >>> # User Pulkit Goyal <7895pul...@gmail.com>
> >>> # Date 1499274297 -19800
> >>> #  Wed Jul 05 22:34:57 2017 +0530
> >>> # Node ID 64c39cf4b61475a133f88fa6dd247ca4f3d61436
> >>> # Parent  8e6f4939a69ae8949e134d97de6b766799bca8de
> >>> # EXP-Topic fbext
> >>> commitextras: move fb's extension which add extras to a commit to core
> >>>
> >>> Facebook has this as extension which adds a flag to `hg commit` to add 
> >>> extra
> >>> values to a commit from command line. This patch moves that extension to 
> >>> core by
> >>> adding that flag and marking that as ADVANCED. Also this patch adds a 
> >>> function
> >>> to check if any key which is used internally can't be used.
> >>
> >> FYI, the last attempt was rejected.
> >>
> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2014-March/056889.html
> >
> > Ha, I was going to dig that message up as well.
> >
> >> I don't know if ADVANCED flag can make the "high barrier" enough to 
> >> discourage
> >> an abuse of extras.
> >
> > I agree with this and with Matt's original criticism. Can this not be an
> > extension instead?
> 
> How about make a debugcommit command that adds this flag and delegates
> everything else to the regular commit command?

debugcommit seems fine.

FWIW, --extra value will need some encoding handling depending on its
type, e.g. convert labels to utf-8, but keep file path as bytes.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 12 of 14] vfs: add the possibility to have a "ward" to check vfs usage

[Yuya Nishihara]

On Thu, 06 Jul 2017 20:53:50 +0200, Boris Feld wrote:
> On Wed, 2017-07-05 at 23:55 +0900, Yuya Nishihara wrote:
> > On Sun, 02 Jul 2017 04:56:37 +0200, Pierre-Yves David wrote:
> > > # HG changeset patch
> > > # User Pierre-Yves David 
> > > # Date 1470323266 -7200
> > > #  Thu Aug 04 17:07:46 2016 +0200
> > > # Node ID ebf81efdd6d7ff15c64683933635616c00475688
> > > # Parent  34b8be7f0420b07d0f7b71379c6055e5b26223d5
> > > # EXP-Topic vfs.ward
> > > # Available At https://www.mercurial-scm.org/repo/users/marmoute/me
> > > rcurial/
> > > #  hg pull https://www.mercurial-scm.org/repo/users/mar
> > > moute/mercurial/ -r ebf81efdd6d7
> > > vfs: add the possibility to have a "ward" to check vfs usage
> > > The feature has some similarity with the 'pathauditor', but further
> > > digging
> > > show it make more sense to keep them separated. The path auditor is
> > > fairly
> > > autonomous (create from vfs.__init__ without any extra
> > > information), and check
> > > very generic details. On the other hand, the wards will have deeper
> > > knownledge
> > > of the Mercurial logic and is created at the local repository
> > > level. Mixing the
> > > two would add much complexity for no real gains.
> > 
> > My gut feeling is that vfs isn't the right place if they require
> > deeper
> > knowledge of repository/dirstate logic. And the whole weakref
> > business
> > floating around wards, hooks and transaction seems like just getting
> > around
> > layering violation.
> 
> We pondered on this choice a long time and couldn't find any other
> layer that is used by both Mercurial core and the extensions to access
> the file system. It seems to be the highest abstraction layer we could
> hook into without introducing a new one and updating all callers.
> 
> Our reflexion is, as the vfs classes comes from the scmutil file, it
> seems okay to have scm related logic in that layer.

IIRC, one possible alternative was to move lock itself to a vfs as the
whole vfs is theoretically covered by the lock.

BTW, the ward itself doesn't require deeper knowledge of repo object right
now. Neither does the auditor. How will the ward API be evolved to depend
on repository-level data?

> > Do you have any idea how to expand this ward() callback to the other
> > vfs
> > operations, which have different set of parameters?
> 
> All other operations (move, delete, copy, etc) could be "translated" to
> 'read' or 'write' mode. An alternative would be to abstract the mode
> with a couple of symbolic constant "create, update, append, delete, …".
> What do you think?

So it will be quite similar to audit(path) if it had a mode flag?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 08 of 10] effectflag: detect when parents changed

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345776 -7200
#  Thu Jul 06 14:56:16 2017 +0200
# Node ID 96a9902a0c2a2c93e7e2a672fb682c845cfcbb88
# Parent  194f5c17a9d460ac0376c9d5dd215c8d6222b3ed
# EXP-Topic effectflag
effectflag: detect when parents changed

Store in effect flag when the parents changed between the predecessor and
its successors.

It can happens with "hg rebase" or "hg grab".

diff -r 194f5c17a9d4 -r 96a9902a0c2a mercurial/obsutil.py
--- a/mercurial/obsutil.py  Thu Jul 06 14:55:12 2017 +0200
+++ b/mercurial/obsutil.py  Thu Jul 06 14:56:16 2017 +0200
@@ -538,6 +538,7 @@
 
 # logic around storing and using effect flags
 DESCCHANGED = 1 << 0 # action changed the description
+PARENTCHANGED = 1 << 2 # action change the parent
 USERCHANGED = 1 << 4 # the user changed
 DATECHANGED = 1 << 5 # the date changed
 BRANCHCHANGED = 1 << 6 # the branch changed
@@ -567,4 +568,8 @@
 if changectx.branch() != source.branch():
 effects |= BRANCHCHANGED
 
+# Check if at least one of the parent has changed
+if changectx.parents() != source.parents():
+effects |= PARENTCHANGED
+
 return effects
diff -r 194f5c17a9d4 -r 96a9902a0c2a tests/test-obsmarkers-effectflag.t
--- a/tests/test-obsmarkers-effectflag.tThu Jul 06 14:55:12 2017 +0200
+++ b/tests/test-obsmarkers-effectflag.tThu Jul 06 14:56:16 2017 +0200
@@ -82,7 +82,7 @@
 check result
 
   $ hg debugobsolete --rev .
-  c85eff83a0340efd9da52b806a94c350222f3371 
da86aa2f19a30d6686b15cae15c7b6c908ec9699 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  c85eff83a0340efd9da52b806a94c350222f3371 
da86aa2f19a30d6686b15cae15c7b6c908ec9699 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '4', 'user': 'test'}
 
 amend touching the diff
 ---
@@ -153,7 +153,7 @@
   rebasing 20:b57fed8d8322 "H1"
   merging H0
   $ hg debugobsolete -r tip
-  b57fed8d83228a8ae3748d8c3760a77638dd4f8c 
e509e2eb3df5d131ff7c02350bf2a9edd0c09478 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  b57fed8d83228a8ae3748d8c3760a77638dd4f8c 
e509e2eb3df5d131ff7c02350bf2a9edd0c09478 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '4', 'user': 'test'}
 
 amend closing the branch should be detected as meta change
 --
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 01 of 10] obsolete: clean createmarkers part about operation

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345167 -7200
#  Thu Jul 06 14:46:07 2017 +0200
# Node ID 030b6e711be36cf764cb053e1d74d71125d63076
# Parent  89796a25d4bb91fb418ad3e70faad2c586902ffb
# EXP-Topic effectflag
obsolete: clean createmarkers part about operation

I will add another experiment in createmarkers, add a comment and some blank
lines for aesthetic sake.

diff -r 89796a25d4bb -r 030b6e711be3 mercurial/obsolete.py
--- a/mercurial/obsolete.py Mon Jul 03 11:22:00 2017 +0200
+++ b/mercurial/obsolete.py Thu Jul 06 14:46:07 2017 +0200
@@ -989,11 +989,14 @@
 metadata = {}
 if 'user' not in metadata:
 metadata['user'] = repo.ui.username()
+
+# Operation metadata handling
 useoperation = repo.ui.configbool('experimental',
   'evolution.track-operation',
   False)
 if useoperation and operation:
 metadata['operation'] = operation
+
 tr = repo.transaction('add-obsolescence-marker')
 try:
 markerargs = []
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 07 of 10] effectflag: detect when branch changed

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345712 -7200
#  Thu Jul 06 14:55:12 2017 +0200
# Node ID 194f5c17a9d460ac0376c9d5dd215c8d6222b3ed
# Parent  7bf0e2d03ccfd013693ecef6aff79804ed1b97d6
# EXP-Topic effectflag
effectflag: detect when branch changed

Store in effect flag when the branch changed between the predecessor and
its successors.

It can happens with "hg branch" + "hg commit --amend", "hg amend" or
"histedit".

diff -r 7bf0e2d03ccf -r 194f5c17a9d4 mercurial/obsutil.py
--- a/mercurial/obsutil.py  Thu Jul 06 14:54:22 2017 +0200
+++ b/mercurial/obsutil.py  Thu Jul 06 14:55:12 2017 +0200
@@ -540,6 +540,7 @@
 DESCCHANGED = 1 << 0 # action changed the description
 USERCHANGED = 1 << 4 # the user changed
 DATECHANGED = 1 << 5 # the date changed
+BRANCHCHANGED = 1 << 6 # the branch changed
 
 def geteffectflag(relation):
 """ From an obs-marker relation, compute what changed between the
@@ -562,4 +563,8 @@
 if changectx.date() != source.date():
 effects |= DATECHANGED
 
+# Check if branch has changed
+if changectx.branch() != source.branch():
+effects |= BRANCHCHANGED
+
 return effects
diff -r 7bf0e2d03ccf -r 194f5c17a9d4 tests/test-obsmarkers-effectflag.t
--- a/tests/test-obsmarkers-effectflag.tThu Jul 06 14:54:22 2017 +0200
+++ b/tests/test-obsmarkers-effectflag.tThu Jul 06 14:55:12 2017 +0200
@@ -66,7 +66,7 @@
 
   $ hg debugobsolete --rev .
   4d1430a201c1ffbd8465dec75edd4a691a2d97ec 0 
{bd3db8264ceebf1966319f5df3be7aac6acd1a8e} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
-  bd3db8264ceebf1966319f5df3be7aac6acd1a8e 
14a01456e0574f0e0a0b15b2345486a6364a8d79 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  bd3db8264ceebf1966319f5df3be7aac6acd1a8e 
14a01456e0574f0e0a0b15b2345486a6364a8d79 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '64', 'user': 'test'}
 
   $ hg up default
   0 files updated, 0 files merged, 1 files removed, 0 files unresolved
@@ -109,7 +109,7 @@
 
   $ hg debugobsolete --rev .
   3b12912003b4e7aa6df6cded86255006c3c29d27 0 
{fad47e5bd78e6aa4db1b5a0a1751bc12563655ff} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
-  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '49', 'user': 'test'}
+  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '113', 'user': 'test'}
 
 rebase not touching the diff
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 04 of 10] effectflag: detect when description changed

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345554 -7200
#  Thu Jul 06 14:52:34 2017 +0200
# Node ID a00ff3d815d246d40a0add309119e98373f5d9f5
# Parent  f5418d3695e7533ddc67917c423d976b367d52d6
# EXP-Topic effectflag
effectflag: detect when description changed

Store in effect flag when the description changed between the predecessor and
its successors.

It can happens with "hg commit --amend", "hg amend" or "histedit".

diff -r f5418d3695e7 -r a00ff3d815d2 mercurial/obsutil.py
--- a/mercurial/obsutil.py  Thu Jul 06 14:51:08 2017 +0200
+++ b/mercurial/obsutil.py  Thu Jul 06 14:52:34 2017 +0200
@@ -536,6 +536,9 @@
 cache[current] = final
 return cache[initialnode]
 
+# logic around storing and using effect flags
+DESCCHANGED = 1 << 0 # action changed the description
+
 def geteffectflag(relation):
 """ From an obs-marker relation, compute what changed between the
 predecessor and the successor.
@@ -544,4 +547,9 @@
 
 source = relation[0]
 
+for changectx in relation[1]:
+# Check if description has changed
+if changectx.description() != source.description():
+effects |= DESCCHANGED
+
 return effects
diff -r f5418d3695e7 -r a00ff3d815d2 tests/test-obsmarkers-effectflag.t
--- a/tests/test-obsmarkers-effectflag.tThu Jul 06 14:51:08 2017 +0200
+++ b/tests/test-obsmarkers-effectflag.tThu Jul 06 14:52:34 2017 +0200
@@ -29,7 +29,7 @@
 check result
 
   $ hg debugobsolete --rev .
-  471f378eab4c5e25f6c77f785b27c936efb22874 
fdf9bde5129a28d4548fadd3f62b265cdd3b7a2e 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  471f378eab4c5e25f6c77f785b27c936efb22874 
fdf9bde5129a28d4548fadd3f62b265cdd3b7a2e 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '1', 'user': 'test'}
 
 amend touching the user only
 
@@ -109,7 +109,7 @@
 
   $ hg debugobsolete --rev .
   3b12912003b4e7aa6df6cded86255006c3c29d27 0 
{fad47e5bd78e6aa4db1b5a0a1751bc12563655ff} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
-  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '1', 'user': 'test'}
 
 rebase not touching the diff
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 05 of 10] effectflag: detect when user changed

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345628 -7200
#  Thu Jul 06 14:53:48 2017 +0200
# Node ID 765f9c129b4e67e92f52075e00bfb4f3c24094f6
# Parent  a00ff3d815d246d40a0add309119e98373f5d9f5
# EXP-Topic effectflag
effectflag: detect when user changed

Store in effect flag when the description changed between the predecessor and
its successors.

It can happens with "hg commit --amend -u" or "histedit".

diff -r a00ff3d815d2 -r 765f9c129b4e mercurial/obsutil.py
--- a/mercurial/obsutil.py  Thu Jul 06 14:52:34 2017 +0200
+++ b/mercurial/obsutil.py  Thu Jul 06 14:53:48 2017 +0200
@@ -538,6 +538,7 @@
 
 # logic around storing and using effect flags
 DESCCHANGED = 1 << 0 # action changed the description
+USERCHANGED = 1 << 4 # the user changed
 
 def geteffectflag(relation):
 """ From an obs-marker relation, compute what changed between the
@@ -552,4 +553,8 @@
 if changectx.description() != source.description():
 effects |= DESCCHANGED
 
+# Check if user has changed
+if changectx.user() != source.user():
+effects |= USERCHANGED
+
 return effects
diff -r a00ff3d815d2 -r 765f9c129b4e tests/test-obsmarkers-effectflag.t
--- a/tests/test-obsmarkers-effectflag.tThu Jul 06 14:52:34 2017 +0200
+++ b/tests/test-obsmarkers-effectflag.tThu Jul 06 14:53:48 2017 +0200
@@ -40,7 +40,7 @@
 check result
 
   $ hg debugobsolete --rev .
-  ef4a313b1e0ade55718395d80e6b88c5ccd875eb 
5485c92d34330dac9d7a63dc07e1e3373835b964 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  ef4a313b1e0ade55718395d80e6b88c5ccd875eb 
5485c92d34330dac9d7a63dc07e1e3373835b964 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '16', 'user': 'test'}
 
 amend touching the date only
 
@@ -109,7 +109,7 @@
 
   $ hg debugobsolete --rev .
   3b12912003b4e7aa6df6cded86255006c3c29d27 0 
{fad47e5bd78e6aa4db1b5a0a1751bc12563655ff} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
-  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '1', 'user': 'test'}
+  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '17', 'user': 'test'}
 
 rebase not touching the diff
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 09 of 10] effectflag: detect when meta changed

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345924 -7200
#  Thu Jul 06 14:58:44 2017 +0200
# Node ID 6a40d87dfedcce4064eb4bcdb131ed4d427fd4de
# Parent  96a9902a0c2a2c93e7e2a672fb682c845cfcbb88
# EXP-Topic effectflag
effectflag: detect when meta changed

Store in effect flag when the meta changed between the predecessor and its
successors. We blacklisted some known meta that would always changed when
another flag change. For example rebase would always add a meta rebase-source
while the effect flag parents will already detect this situation.

It can happens with various hg commands.

diff -r 96a9902a0c2a -r 6a40d87dfedc mercurial/obsutil.py
--- a/mercurial/obsutil.py  Thu Jul 06 14:56:16 2017 +0200
+++ b/mercurial/obsutil.py  Thu Jul 06 14:58:44 2017 +0200
@@ -7,6 +7,8 @@
 
 from __future__ import absolute_import
 
+import re
+
 from . import (
 phases,
 )
@@ -538,11 +540,31 @@
 
 # logic around storing and using effect flags
 DESCCHANGED = 1 << 0 # action changed the description
+METACHANGED = 1 << 1 # action change the meta
 PARENTCHANGED = 1 << 2 # action change the parent
 USERCHANGED = 1 << 4 # the user changed
 DATECHANGED = 1 << 5 # the date changed
 BRANCHCHANGED = 1 << 6 # the branch changed
 
+METABLACKLIST = [
+re.compile('^__touch-noise__$'),
+re.compile('^branch$'),
+re.compile('^.*-source$'),
+re.compile('^.*_source$'),
+re.compile('^source$'),
+]
+
+def ismetablacklisted(metaitem):
+""" Check that the key of a meta item (extrakey, extravalue) does not
+match at least one of the blacklist pattern
+"""
+metakey = metaitem[0]
+for pattern in METABLACKLIST:
+if pattern.match(metakey):
+return False
+
+return True
+
 def geteffectflag(relation):
 """ From an obs-marker relation, compute what changed between the
 predecessor and the successor.
@@ -572,4 +594,14 @@
 if changectx.parents() != source.parents():
 effects |= PARENTCHANGED
 
+# Check if other meta has changed
+changeextra = changectx.extra().items()
+ctxmeta = filter(ismetablacklisted, changeextra)
+
+sourceextra = source.extra().items()
+srcmeta = filter(ismetablacklisted, sourceextra)
+
+if ctxmeta != srcmeta:
+effects |= METACHANGED
+
 return effects
diff -r 96a9902a0c2a -r 6a40d87dfedc tests/test-obsmarkers-effectflag.t
--- a/tests/test-obsmarkers-effectflag.tThu Jul 06 14:56:16 2017 +0200
+++ b/tests/test-obsmarkers-effectflag.tThu Jul 06 14:58:44 2017 +0200
@@ -168,4 +168,4 @@
 
   $ hg debugobsolete -r .
   2b5d9213db9e0e240052e89aad86f7c7a5fb3822 0 
{2f599e54c1c6974299065cdf54e1ad640bfb7b5d} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
-  2f599e54c1c6974299065cdf54e1ad640bfb7b5d 
12c6238b5e371eea00fd2013b12edce3f070928b 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  2f599e54c1c6974299065cdf54e1ad640bfb7b5d 
12c6238b5e371eea00fd2013b12edce3f070928b 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '2', 'user': 'test'}
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 03 of 10] tests: add tests for effect flags

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345468 -7200
#  Thu Jul 06 14:51:08 2017 +0200
# Node ID f5418d3695e7533ddc67917c423d976b367d52d6
# Parent  ac20a70e9d253605b5be4f60f8791846a3cc00f6
# EXP-Topic effectflag
tests: add tests for effect flags

Add all the tests in this patch, it makes the patch quite big but will clearly
show the impact of following patches on the store effect flag value.

diff -r ac20a70e9d25 -r f5418d3695e7 tests/test-obsmarkers-effectflag.t
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/tests/test-obsmarkers-effectflag.tThu Jul 06 14:51:08 2017 +0200
@@ -0,0 +1,171 @@
+Test the 'effect-flags' feature
+
+Global setup
+
+
+  $ . $TESTDIR/testlib/obsmarker-common.sh
+  $ cat >> $HGRCPATH < [ui]
+  > interactive = true
+  > [phases]
+  > publish=False
+  > [extensions]
+  > rebase =
+  > [experimental]
+  > evolution = all
+  > evolution.effect-flags = 1
+  > EOF
+
+  $ hg init $TESTTMP/effect-flags
+  $ cd $TESTTMP/effect-flags
+  $ mkcommit ROOT
+
+amend touching the description only
+---
+
+  $ mkcommit A0
+  $ hg commit --amend -m "A1"
+
+check result
+
+  $ hg debugobsolete --rev .
+  471f378eab4c5e25f6c77f785b27c936efb22874 
fdf9bde5129a28d4548fadd3f62b265cdd3b7a2e 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+amend touching the user only
+
+
+  $ mkcommit B0
+  $ hg commit --amend -u "bob "
+
+check result
+
+  $ hg debugobsolete --rev .
+  ef4a313b1e0ade55718395d80e6b88c5ccd875eb 
5485c92d34330dac9d7a63dc07e1e3373835b964 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+amend touching the date only
+
+
+  $ mkcommit B1
+  $ hg commit --amend -d "42 0"
+
+check result
+
+  $ hg debugobsolete --rev .
+  2ef0680ff45038ac28c9f1ff3644341f54487280 
4dd84345082e9e5291c2e6b3f335bbf8bf389378 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+amend touching the branch only
+
+
+  $ mkcommit B2
+  $ hg branch my-branch
+  marked working directory as branch my-branch
+  (branches are permanent and global, did you want a bookmark?)
+  $ hg commit --amend
+
+check result
+
+  $ hg debugobsolete --rev .
+  4d1430a201c1ffbd8465dec75edd4a691a2d97ec 0 
{bd3db8264ceebf1966319f5df3be7aac6acd1a8e} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  bd3db8264ceebf1966319f5df3be7aac6acd1a8e 
14a01456e0574f0e0a0b15b2345486a6364a8d79 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+  $ hg up default
+  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
+
+rebase (parents change)
+---
+
+  $ mkcommit C0
+  $ mkcommit D0
+  $ hg rebase -r . -d 'desc(B0)'
+  rebasing 11:c85eff83a034 "D0" (tip)
+
+check result
+
+  $ hg debugobsolete --rev .
+  c85eff83a0340efd9da52b806a94c350222f3371 
da86aa2f19a30d6686b15cae15c7b6c908ec9699 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+amend touching the diff
+---
+
+  $ mkcommit E0
+  $ echo 42 >> E0
+  $ hg commit --amend
+
+check result
+
+  $ hg debugobsolete --rev .
+  d6f4d8b8d3c8cde990f13915bced7f92ce1cc54f 0 
{ebfe0333e0d96f68a917afd97c0a0af87f1c3b5f} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  ebfe0333e0d96f68a917afd97c0a0af87f1c3b5f 
75781fdbdbf58a987516b00c980bccda1e9ae588 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+amend with multiple effect (desc and meta)
+---
+
+  $ mkcommit F0
+  $ hg branch my-other-branch
+  marked working directory as branch my-other-branch
+  $ hg commit --amend -m F1 -u "bob " -d "42 0"
+
+check result
+
+  $ hg debugobsolete --rev .
+  3b12912003b4e7aa6df6cded86255006c3c29d27 0 
{fad47e5bd78e6aa4db1b5a0a1751bc12563655ff} (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+  fad47e5bd78e6aa4db1b5a0a1751bc12563655ff 
a94e0fd5f1c81d969381a76eb0d37ce499a44fae 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+rebase not touching the diff
+
+
+  $ cat << EOF > H0
+  > 0
+  > 1
+  > 2
+  > 3
+  > 4
+  > 5
+  > 6
+  > 7
+  > 8
+  > 9
+  > 10
+  > EOF
+  $ hg add H0
+  $ hg commit -m 'H0'
+  $ echo "H1" >> H0
+  $ hg commit -m "H1"
+  $ hg up -r "desc(H0)"
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  $ cat << EOF > H0
+  > H2
+  > 0
+  > 1
+  > 2
+  > 3
+  > 4
+  > 5
+  > 6
+  > 7
+  > 8
+  > 9
+  > 10
+  > EOF
+  $ hg commit -m "H2"
+  created new head
+  $ hg rebase -s "desc(H1)" -d "desc(H2)" -t :merge3
+  rebasing 20:b57fed8d8322 "H1"
+  merging H0
+  $ hg debugobsolete -r tip
+  b57fed8d83228a8ae3748d8c3760a77638dd4f8c 
e509e2eb3df5d131ff7c02350bf2a9edd0c09478 0 (Thu Jan 01 00:00:00 1970 +) 
{'ef1': '0', 'user': 'test'}
+
+amend closing the branch should be detected as meta change

[PATCH 02 of 10] effectflag: store an empty effect flag right now

[Boris Feld]

# HG changeset patch
# User Boris Feld 
# Date 1499345417 -7200
#  Thu Jul 06 14:50:17 2017 +0200
# Node ID ac20a70e9d253605b5be4f60f8791846a3cc00f6
# Parent  030b6e711be36cf764cb053e1d74d71125d63076
# EXP-Topic effectflag
effectflag: store an empty effect flag right now

The idea is to store a bitfield flag when creating an obsmarker. This effect
flag would indicate what is the changes between a changeset and its successor.
It is only informative and helps people collaborating together on the same
stack or even people trying to find the  version of their changeset before
rebasing to check if a bug was already there or not.

Hook the saving of effect flag in create markers but store only an empty one
for the moment, I will refine the values in effect flag in following patches.

diff -r 030b6e711be3 -r ac20a70e9d25 mercurial/obsolete.py
--- a/mercurial/obsolete.py Thu Jul 06 14:46:07 2017 +0200
+++ b/mercurial/obsolete.py Thu Jul 06 14:50:17 2017 +0200
@@ -997,6 +997,11 @@
 if useoperation and operation:
 metadata['operation'] = operation
 
+# Effect flag metadata handling
+saveeffectflag = repo.ui.configbool('experimental',
+'evolution.effect-flags',
+False)
+
 tr = repo.transaction('add-obsolescence-marker')
 try:
 markerargs = []
@@ -1020,6 +1025,12 @@
 raise error.Abort(_("changeset %s cannot obsolete itself")
   % prec)
 
+# Effect flag can be different by relation
+if saveeffectflag:
+# The effect flag is saved in a versioned field name for future
+# evolution
+localmetadata["ef1"] = "%d" % obsutil.geteffectflag(rel)
+
 # Creating the marker causes the hidden cache to become invalid,
 # which causes recomputation when we ask for prec.parents() above.
 # Resulting in n^2 behavior.  So let's prepare all of the args
diff -r 030b6e711be3 -r ac20a70e9d25 mercurial/obsutil.py
--- a/mercurial/obsutil.py  Thu Jul 06 14:46:07 2017 +0200
+++ b/mercurial/obsutil.py  Thu Jul 06 14:50:17 2017 +0200
@@ -535,3 +535,13 @@
 final.reverse() # put small successors set first
 cache[current] = final
 return cache[initialnode]
+
+def geteffectflag(relation):
+""" From an obs-marker relation, compute what changed between the
+predecessor and the successor.
+"""
+effects = 0
+
+source = relation[0]
+
+return effects
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] revset: add experimental set subscript operator

[Yuya Nishihara]

On Thu, 06 Jul 2017 19:04:48 -0700, Sean Farley wrote:
> Jun Wu  writes:
> > Excerpts from Sean Farley's message of 2017-07-01 16:33:47 -0700:
> >> > Yep. That's why I slightly prefer not using "{}".
> >> >
> >> >   $ hg log -T '{revset(".{0}")}\n'
> >> >  ^^^
> >> >this is not a revset operator, but expanded to ''
> >> 
> >> I like separating {} and [] so that foo{4}[1] is the 4th level of
> >> descendants of foo and the [1] would be the index in that list (ordered
> >> by rev num?).
> >
> > Could it be foo[+4][1] meaning what you want? An explicit "+" means it's an
> > offset, the "1" without a "+" means it's a normal index.
> 
> Hmmm, I'll have to mull on that. My gut feeling is that it might be too
> magical. Though, we're severely limited on characters so it might be the
> least-worst option.

It's confusing. You might think foo[-1] will return the last element in foo.

If we don't want to use {} but also want to reserve [] for future use, we'll
need a completely different operator, e.g. foo[[4]], foo~[4] foo#[4].
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 9] template: add minimal obsfate template

[Yuya Nishihara]

On Thu, 6 Jul 2017 17:05:01 -0700, Jun Wu wrote:
> I'm not a big fan of this obsfate template approach. Ideally we could
> extract information from an obsmarker using templates. Something like
> "{marker.user} {marker.operation} {marker.}".

"{get(marker, 'user')}", perhaps. We could add a syntactic sugar for that.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 4 of 9] template: add minimal obsfate template

[Boris Feld]

On Thu, 2017-07-06 at 18:13 -0700, Sean Farley wrote:
> Jun Wu  writes:
> 
> > I'm not a big fan of this obsfate template approach. Ideally we
> > could
> > extract information from an obsmarker using templates. Something
> > like
> > "{marker.user} {marker.operation} {marker.}". That's much more
> > flexible
> > and could work with colors trivially.
> 
> Heh, I was writing almost the same email.
> 
> > The current template is binded to a
> > ctx. We could define some functions or introduce special synctax to
> > make it
> > bind to an obsmarker.
> 
> Hmm, maybe. I'm not sure the marker information would be concise
> enough.
> At the very least, I think we could do that in another series as an
> experiment.
> 
> It might turn out that we need more functionality in the template
> engine
> as well.

I've answered to sean email on Patch 9 as it introduce more templating
capabilities, could we merge the two discussion there?

Cheers,

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

Re: [PATCH 9 of 9] template: use template-engine for obsfate

[Boris Feld]

On Thu, 2017-07-06 at 18:05 -0700, Sean Farley wrote:
> Boris Feld  writes:
> 
> > # HG changeset patch
> > # User Boris Feld 
> > # Date 1499085172 -7200
> > #  Mon Jul 03 14:32:52 2017 +0200
> > # Node ID e18d8e61b7260e246a82727c8cde01f936692cff
> > # Parent  098585d4fbc88dc54513e12fa306d0e52ea2b323
> > # EXP-Topic obsfatetemplate
> > template: use template-engine for obsfate
> > 
> > Try to replace the obsfateprinter part by "sub-templates".
> > 
> > The code is hacky, I've tried to use at maximum the template engine
> > but the
> > raw data-structure doesn't seems well supported:
> > 
> > [{'markers': [{}, {}, ...], 'successors': [A, ...], 'verb': '',
> > ...}, ...]
> > 
> > I've put this changeset at the end so the beginning of the serie
> > might be
> > accepted without it. Even without this changeset, we already have
> > good tests
> > and the right structure for the computation of obsfate data.
> 
> I like the general sentiment of this series, so thanks for that! But
> by
> the end of reading the series I found myself want to customize (e.g.
> not
> include some of the info; colorize differently, etc.) the string.
> 
> I think an easy approach for now (unless I'm missing something) would
> be
> to make {obsfate} a meta-like template that is just an alias for
> finer
> grain templates: {obsfate_user} {obsfate_succesors} (or whatever name
> you prefer).

Interesting, I didn't think about your use-cases much.

The main twist in obsfate is that the value is a list. The list could
contains 1 element in case of a simple evolution or several elements in
case of a divergence. We could have a top-level template
{obsfate_users} being a list of list, but it would be hard to combine
with another top-level template {obsfate_verb} for example.

Also, I just found out that it's possible to access the data with the
template engine.

For example if you only want the verb and the users:
hg log -G -T '{obsfate % "obsolete: {get(obsfate, "verb")} by
{get(obsfate, "users")}\n"}'

Which would returns "obsolete: rewritten by test" in simple cases.
Unfortunately it fails with multiple users "obsolete: rewritten by
test1test2"

I tried changing the template into:

hg log -G -T '{obsfate % "obsolete: {get(obsfate, "verb")} by
{join(get(obsfate, "users"), ', ')}\n"}'

Unfortunately I only get a blank output, maybe a template engine
experts could help me identify what am I doing wrong.

Apart from this problem, do you think is it customizable enough for
your needs?

We can even access the markers with:

$ hg log -T '{obsfate % "obsolete: {ge
t(obsfate, "markers")|json}\n"}'
obsolete: [["471f378eab4c5e25f6c77f785b27c936efb22874",
["fdf9bde5129a28d4548fadd3f62b265cdd3b7a2e"], 0, [["user", "test"]],
[0.0, 0], null]]
obsolete: [["471f378eab4c5e25f6c77f785b27c936efb22874",
["65b757b745b935093c87a2bccd877521cccffcbd"], 0, [["user", "test"]],
[0.0, 0], null], ["65b757b745b935093c87a2bccd877521cccffcbd",
["019fadeab383f6699fa83ad7bdb4d82ed2c0e5ab"], 0, [["user", "test"]],
[0.0, 0], null]]

However, I'm not sure what would be the use-cases to accessing the
markers as obsfate is designed to show a summary of the evolution of a
changeset. There could be multiple successorsets in case of divergence
and several markers for each successorsets in case the changeset has
been rewritten several times.

Cheers,

> 
> I have the same critique for 'hg show' as well (*cough* Greg
> *cough*).
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 2] tests: add tests for typoed commands

[Martin von Zweigbergk via Mercurial-devel]

# HG changeset patch
# User Martin von Zweigbergk 
# Date 1499411564 25200
#  Fri Jul 07 00:12:44 2017 -0700
# Node ID 46c6014cd9765a04b61fe03b907f9eceaabba0dd
# Parent  38df146d06979ae7f5f334b5a55fdaf779b3f19a
tests: add tests for typoed commands

This includes one test showing how disabling a command with e.g.
"extensions.rebase=!" results in the command not being
suggested. We'll fix that next.

diff --git a/tests/test-help.t b/tests/test-help.t
--- a/tests/test-help.t
+++ b/tests/test-help.t
@@ -660,6 +660,28 @@
   (use 'hg help' for the full list of commands or 'hg -v' for details)
   [255]
 
+Typoed command gives suggestion
+  $ hg puls
+  hg: unknown command 'puls'
+  (did you mean one of pull, push?)
+  [255]
+
+Not enabled extension gets suggested
+
+  $ hg rebase
+  hg: unknown command 'rebase'
+  'rebase' is provided by the following extension:
+  
+  rebasecommand to move sets of revisions to a different ancestor
+  
+  (use 'hg help extensions' for information on enabling extensions)
+  [255]
+
+Disabled extension gets suggested
+  $ hg --config extensions.rebase=! rebase
+  hg: unknown command 'rebase'
+  (did you mean one of rename, resolve?)
+  [255]
 
 Make sure that we don't run afoul of the help system thinking that
 this is a section and erroring out weirdly.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2] dispatch: fix typo suggestion for disabled extension

[Martin von Zweigbergk via Mercurial-devel]

# HG changeset patch
# User Martin von Zweigbergk 
# Date 1499411633 25200
#  Fri Jul 07 00:13:53 2017 -0700
# Node ID f968eaa9c1e45e19a90423d875d1538ebb30d884
# Parent  46c6014cd9765a04b61fe03b907f9eceaabba0dd
dispatch: fix typo suggestion for disabled extension

If the matching command lives in an in-tree extension (which is all we
scan for), and the user has disabled that extension with
"extensions.=!", we were not finding it, because the path in
_disabledextensions was the empty string. If the user had set
"extensions.=!" it would work, so it seems like just
a mistake that it didn't work.

diff --git a/mercurial/extensions.py b/mercurial/extensions.py
--- a/mercurial/extensions.py
+++ b/mercurial/extensions.py
@@ -494,7 +494,11 @@
 if name in exts or name in _order or name == '__init__':
 continue
 exts[name] = path
-exts.update(_disabledextensions)
+for name, path in _disabledextensions.iteritems():
+# If no path was provided for a disabled extension (e.g. "color=!"),
+# don't replace the path we already found by the scan above.
+if path:
+exts[name] = path
 return exts
 
 def _moduledoc(file):
diff --git a/tests/test-help.t b/tests/test-help.t
--- a/tests/test-help.t
+++ b/tests/test-help.t
@@ -680,7 +680,11 @@
 Disabled extension gets suggested
   $ hg --config extensions.rebase=! rebase
   hg: unknown command 'rebase'
-  (did you mean one of rename, resolve?)
+  'rebase' is provided by the following extension:
+  
+  rebasecommand to move sets of revisions to a different ancestor
+  
+  (use 'hg help extensions' for information on enabling extensions)
   [255]
 
 Make sure that we don't run afoul of the help system thinking that
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 2 v4] hgweb: use ui._unset to get prevent a warning in configitems

[David Demelier]

Sorry, small typo in the commit message. Next time I'll complete my
coffee before calling hg email.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 2 v4] hgweb: use ui._unset to get prevent a warning in configitems

[David Demelier]

# HG changeset patch
# User David Demelier 
# Date 1499079875 -7200
#  Mon Jul 03 13:04:35 2017 +0200
# Node ID d32ff523e0219b48b119d9dc44d9d07638153a72
# Parent  5c9ad50fd62fbc2057ef7b44f921f22e7359af32
hgweb: use ui._unset to get prevent a warning in configitems

diff -r 5c9ad50fd62f -r d32ff523e021 mercurial/hgweb/hgweb_mod.py
--- a/mercurial/hgweb/hgweb_mod.py  Wed Jun 28 13:32:36 2017 +0200
+++ b/mercurial/hgweb/hgweb_mod.py  Mon Jul 03 13:04:35 2017 +0200
@@ -119,19 +119,19 @@
 self.csp, self.nonce = cspvalues(self.repo.ui)
 
 # Trust the settings from the .hg/hgrc files by default.
-def config(self, section, name, default=None, untrusted=True):
+def config(self, section, name, default=uimod._unset, untrusted=True):
 return self.repo.ui.config(section, name, default,
untrusted=untrusted)
 
-def configbool(self, section, name, default=False, untrusted=True):
+def configbool(self, section, name, default=uimod._unset, untrusted=True):
 return self.repo.ui.configbool(section, name, default,
untrusted=untrusted)
 
-def configint(self, section, name, default=None, untrusted=True):
+def configint(self, section, name, default=uimod._unset, untrusted=True):
 return self.repo.ui.configint(section, name, default,
   untrusted=untrusted)
 
-def configlist(self, section, name, default=None, untrusted=True):
+def configlist(self, section, name, default=uimod._unset, untrusted=True):
 return self.repo.ui.configlist(section, name, default,
untrusted=untrusted)
 
diff -r 5c9ad50fd62f -r d32ff523e021 mercurial/hgweb/hgwebdir_mod.py
--- a/mercurial/hgweb/hgwebdir_mod.py   Wed Jun 28 13:32:36 2017 +0200
+++ b/mercurial/hgweb/hgwebdir_mod.py   Mon Jul 03 13:04:35 2017 +0200
@@ -404,7 +404,7 @@
 except Exception as e:
 u.warn(_('error reading %s/.hg/hgrc: %s\n') % (path, e))
 continue
-def get(section, name, default=None):
+def get(section, name, default=uimod._unset):
 return u.config(section, name, default, untrusted=True)
 
 if u.configbool("web", "hidden", untrusted=True):
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 2 of 2 v4] configitems: add alias support in config

[David Demelier]

# HG changeset patch
# User David Demelier 
# Date 1499409190 -7200
#  Fri Jul 07 08:33:10 2017 +0200
# Node ID 936ce124293ab334d10239c9088c74f47fc55212
# Parent  d32ff523e0219b48b119d9dc44d9d07638153a72
configitems: add alias support in config

Aliases define optional alternatives to existing options. For example the old
option ui.user was deprecated and replaced by ui.username. With this mechanism,
it's even possible to create an alias to an option in a different section.

Add ui.user as alias to ui.username as an example of this concept.

The old alternates principle in ui.config is removed as it was used only for
this option.

diff -r d32ff523e021 -r 936ce124293a mercurial/configitems.py
--- a/mercurial/configitems.py  Mon Jul 03 13:04:35 2017 +0200
+++ b/mercurial/configitems.py  Fri Jul 07 08:33:10 2017 +0200
@@ -32,12 +32,14 @@
 :section: the official config section where to find this item,
:name: the official name within the section,
 :default: default value for this item,
+:alias: optional list of tuples as alternatives.
 """
 
-def __init__(self, section, name, default=None):
+def __init__(self, section, name, default=None, alias=()):
 self.section = section
 self.name = name
 self.default = default
+self.alias = list(alias)
 
 coreitems = {}
 
@@ -95,3 +97,6 @@
 coreconfigitem('ui', 'quiet',
 default=False,
 )
+coreconfigitem('ui', 'username',
+alias=[('ui', 'user')]
+)
diff -r d32ff523e021 -r 936ce124293a mercurial/ui.py
--- a/mercurial/ui.py   Mon Jul 03 13:04:35 2017 +0200
+++ b/mercurial/ui.py   Fri Jul 07 08:33:10 2017 +0200
@@ -448,38 +448,39 @@
 
 def _config(self, section, name, default=_unset, untrusted=False):
 value = default
-if isinstance(name, list):
-alternates = name
-else:
-item = self._knownconfig.get(section, {}).get(name)
-if default is _unset:
-if item is None:
-value = default
-elif callable(item.default):
+item = self._knownconfig.get(section, {}).get(name)
+alternates = [(section, name)]
+
+if item is not None:
+alternates.extend(item.alias)
+
+if default is _unset:
+if item is None:
+value = default
+elif callable(item.default):
 value = item.default()
-else:
-value = item.default
-elif item is not None:
-msg = ("specifying a default value for a registered "
-   "config item: '%s.%s' '%s'")
-msg %= (section, name, default)
-self.develwarn(msg, 2, 'warn-config-default')
+else:
+value = item.default
+elif item is not None:
+msg = ("specifying a default value for a registered "
+   "config item: '%s.%s' '%s'")
+msg %= (section, name, default)
+self.develwarn(msg, 2, 'warn-config-default')
 
-alternates = [name]
-
-for n in alternates:
-candidate = self._data(untrusted).get(section, n, None)
+for s, n in alternates:
+candidate = self._data(untrusted).get(s, n, None)
 if candidate is not None:
 value = candidate
+section = s
 name = n
 break
 
 if self.debugflag and not untrusted and self._reportuntrusted:
-for n in alternates:
-uvalue = self._ucfg.get(section, n)
+for s, n in alternates:
+uvalue = self._ucfg.get(s, n)
 if uvalue is not None and uvalue != value:
 self.debug("ignoring untrusted configuration option "
-   "%s.%s = %s\n" % (section, n, uvalue))
+   "%s.%s = %s\n" % (s, n, uvalue))
 return value
 
 def configsuboptions(self, section, name, default=_unset, untrusted=False):
@@ -744,7 +745,7 @@
 """
 user = encoding.environ.get("HGUSER")
 if user is None:
-user = self.config("ui", ["username", "user"])
+user = self.config("ui", "username")
 if user is not None:
 user = os.path.expandvars(user)
 if user is None:
diff -r d32ff523e021 -r 936ce124293a tests/test-config.t
--- a/tests/test-config.t   Mon Jul 03 13:04:35 2017 +0200
+++ b/tests/test-config.t   Fri Jul 07 08:33:10 2017 +0200
@@ -178,3 +178,36 @@
 
   $ PAGER=p1 hg config --debug --config pager.pager=p2 | grep 'pager\.pager'
   --config: pager.pager=p2
+
+verify that aliases are evaluated as well
+
+  $ hg init aliastest
+  $ cd aliastest
+  $ cat > .hg/hgrc << EOF
+  > [ui]
+  > user = repo user
+  > EOF
+  $ touch index
+  $ unset HGUSER
+  $ hg ci -Am test
+  adding index
+  $ hg log --template '{author}\n'

Re: [PATCH 2 of 2] releasenotes: add similarity check function to compare incoming notes

[Rishabh Madan]

On Wed, Jul 5, 2017 at 3:44 PM, Yuya Nishihara  wrote:

> On Mon, 03 Jul 2017 23:06:31 +0200, Rishabh Madan wrote:
> > # HG changeset patch
> > # User Rishabh Madan 
> > # Date 1499115687 -7200
> > #  Mon Jul 03 23:01:27 2017 +0200
> > # Node ID 1fc4f41fadcca56d36edd0747a09e1be6af5f680
> > # Parent  6684514628b44e838f499b2125ffebe8d700a204
> > releasenotes: add similarity check function to compare incoming notes
>
> Can you think more about how to split testable functions?
>


> For instance, maybe there could be a boolean function that returns whether
> the new paragraph should be added or not.
>
>   if f(section, paragraphs):
>   self.addtitleditem(section, title, paragraphs)
>   ...
>   if f(section, paragraphs):
>   self.addnontitleditem(section, paragraphs)
>
> Since the function 'f' depends on 'all_points', which has wider scope (*1),
> 'f' might be a class that holds pre-computed 'all_points'.
>
>   f = x()
>   x.addknownparagraphs(paragraphs for _title, paragraphs
>in self.titledforsection(section))
>   ...
>

I get what you're trying to suggest. I'll make similar changes and send a
new patch.
ᐧ
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel