Re: [PATCH 2 of 9] chgserver: add a top-level run method
Excerpts from Yuya Nishihara's message of 2016-11-20 13:13:14 +0900: > On Sat, 19 Nov 2016 15:05:55 +, Jun Wu wrote: > > Excerpts from Yuya Nishihara's message of 2016-11-19 18:09:18 +0900: > > > I'm in favor of going through dispatch.dispatch() with some special > > > treatments > > > for chg, but you might be right in that it would be unnecessary > > > complicated. > > > So I'll queue V2 even if it has a top-level run(). > > > > I think some dispatch logic could be helpful (reusable). chgserver also > > needs a ui object, a debugger could be useful, too. > > > > What do you about putting the "if-it-is-chg" condition in "_runcatch" ? > > > > hg -> run -> dispatch -> _runcatch -> _dispatch -> runcommand -> > > _runcommand > >\ \ > > -> chg run (current) -> chg _dispatch (proposal) > > > > The "chg _dispatch" function, if short, could be put just in dispatch.py > > calling chgserver functions. Otherwise it could be "chgserver._dispatch". > > I don't get the meaning of "hg -> chg run (current)", but sharing some > dispatch > functions sounds nice. Ah, it's an unsent patch that changes "hg" script to call "chgserver.run". > > > BTW, I have the patches to move chgserver.py to the core. If they help > > > making > > > your series without the copy of chgserver.py, I'll send them out. But I > > > guess > > > they wouldn't. > > > > If we can allow chg to be broken for some time, then it is fine. The copy is > > like an "atomictemp" to make sure the old code works (and I don't need to > > care about the compatibility, which is a bit tricky to maintain) during the > > change. > > Can you narrow down the breakage to one series of patches by e.g. moving > some cleanup patches to the last series? Perhaps broken for weeks would be > unwanted. The incompatibility will be mainly about the pager. Maybe I could try changing the pager implementation first, then changing the entry point. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 9] chgserver: add a top-level run method
On Sat, 19 Nov 2016 15:05:55 +, Jun Wu wrote: > Excerpts from Yuya Nishihara's message of 2016-11-19 18:09:18 +0900: > > I'm in favor of going through dispatch.dispatch() with some special > > treatments > > for chg, but you might be right in that it would be unnecessary complicated. > > So I'll queue V2 even if it has a top-level run(). > > I think some dispatch logic could be helpful (reusable). chgserver also > needs a ui object, a debugger could be useful, too. > > What do you about putting the "if-it-is-chg" condition in "_runcatch" ? > > hg -> run -> dispatch -> _runcatch -> _dispatch -> runcommand -> _runcommand >\ \ > -> chg run (current) -> chg _dispatch (proposal) > > The "chg _dispatch" function, if short, could be put just in dispatch.py > calling chgserver functions. Otherwise it could be "chgserver._dispatch". I don't get the meaning of "hg -> chg run (current)", but sharing some dispatch functions sounds nice. > > BTW, I have the patches to move chgserver.py to the core. If they help > > making > > your series without the copy of chgserver.py, I'll send them out. But I > > guess > > they wouldn't. > > If we can allow chg to be broken for some time, then it is fine. The copy is > like an "atomictemp" to make sure the old code works (and I don't need to > care about the compatibility, which is a bit tricky to maintain) during the > change. Can you narrow down the breakage to one series of patches by e.g. moving some cleanup patches to the last series? Perhaps broken for weeks would be unwanted. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 5 shelve-ext] shelve: move temporary commit creation to a separate function
On Sun, 20 Nov 2016 00:42:53 +, Kostia Balytskyi wrote:
> On 11/19/16, 10:02 AM, "Yuya Nishihara" y...@tcha.org> wrote:
>
> On Sun, 13 Nov 2016 03:39:34 -0800, Kostia Balytskyi wrote:
> > # HG changeset patch
> > # User Kostia Balytskyi
> > # Date 1479036952 28800
> > # Sun Nov 13 03:35:52 2016 -0800
> > # Node ID 45dbc9a803375958310bced301227b02802372b0
> > # Parent 2188194ca1ee86953855e0d2fb9396ec18636ed9
> > shelve: move temporary commit creation to a separate function
>
> Looks all good. Queued them, thanks.
>
> > +def _commitworkingcopychanges(ui, repo, opts, tmpwctx):
> > +"""Temporarily commit working copy changes before moving unshelve
> commit"""
> > +# Store pending changes in a commit and remember added in case a
> shelve
> > +# contains unknown files that are part of the pending change
> > +s = repo.status()
> > +addedbefore = frozenset(s.added)
> > +if not (s.modified or s.added or s.removed or s.deleted):
> > +return tmpwctx, addedbefore
> > +ui.status(_("temporarily committing pending changes "
> > +"(restore with 'hg unshelve --abort')\n"))
> > +commitfunc = getcommitfunc(extra=None, interactive=False,
> > + editor=False)
> > +tempopts = {}
> > +tempopts['message'] = "pending changes temporary commit"
> > +tempopts['date'] = opts.get('date')
> > +ui.quiet = True
> > +node = cmdutil.commit(ui, repo, commitfunc, [], tempopts)
> > +tmpwctx = repo[node]
> > +return tmpwctx, addedbefore
>
> This and the next unbalanced ui.quiet hack can be a source of future bugs.
> I hope they'll be fixed by a follow-up patch.
> Can you explain please? I was trying to keep the ui.quiet behavior unchanged
> in this refactoring series.
You've split set/restore of ui.quiet to separate functions. It's unclear that
we have to care about the state of ui.quiet when adding some code to
_dounshelve(). So IMO, each function should restore ui.quiet at the end.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] conflicts: make spacing consistent in conflict markers
On Sat, 19 Nov 2016 15:42:54 -0800, Kostia Balytskyi wrote:
> # HG changeset patch
> # User Kostia Balytskyi
> # Date 1479598897 28800
> # Sat Nov 19 15:41:37 2016 -0800
> # Node ID 5f03a63d6def1cf3c34fa7f8979c34151a9ba660
> # Parent 0c3a8b6239db2c0d6a0e9ddea2266445bca2d440
> conflicts: make spacing consistent in conflict markers
>
> The way default marker template was defined before this patch,
> the spacing before dash in conflict markes was dependent on
> whether changeset is a tip one or not. This is a relevant part
> of template:
> '{ifeq(tags, "tip", "", "{tags} "}'
> If revision is a tip revision with no other tags, this would
> resolve to an empty string, but for revisions which are not tip
> and don't have any other tags, this would resolve to a single
> space string. In the end this causes weirdnesses like the ones
> you can see in the affected tests.
>
> This is a not a big deal, but double spacing may be visually
> less pleasant.
>
> Please note that test changes where commit hashes change are
> the result of marking files as resolved without removing markers.
>
> diff --git a/mercurial/filemerge.py b/mercurial/filemerge.py
> --- a/mercurial/filemerge.py
> +++ b/mercurial/filemerge.py
> @@ -518,7 +518,8 @@ def _formatconflictmarker(repo, ctx, tem
> return util.ellipsis(mark, 80 - 8)
>
> _defaultconflictmarker = ('{node|short} '
> - '{ifeq(tags, "tip", "", "{tags} ")}'
> + '{ifeq(tags, "tip", "", '
> + 'ifeq(tags, "", "", "{tags} "))}'
>'{if(bookmarks, "{bookmarks} ")}'
>'{ifeq(branch, "default", "", "{branch} ")}'
>'- {author|user}: {desc|firstline}')
Maybe we can use separate() function.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] conflicts: make spacing consistent in conflict markers
On Sat, Nov 19, 2016 at 03:42:54PM -0800, Kostia Balytskyi wrote: > # HG changeset patch > # User Kostia Balytskyi > # Date 1479598897 28800 > # Sat Nov 19 15:41:37 2016 -0800 > # Node ID 5f03a63d6def1cf3c34fa7f8979c34151a9ba660 > # Parent 0c3a8b6239db2c0d6a0e9ddea2266445bca2d440 > conflicts: make spacing consistent in conflict markers Queued, thanks ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 5 shelve-ext] shelve: move temporary commit creation to a separate function
On 11/19/16, 10:02 AM, "Yuya Nishihara" wrote:
On Sun, 13 Nov 2016 03:39:34 -0800, Kostia Balytskyi wrote:
> # HG changeset patch
> # User Kostia Balytskyi
> # Date 1479036952 28800
> # Sun Nov 13 03:35:52 2016 -0800
> # Node ID 45dbc9a803375958310bced301227b02802372b0
> # Parent 2188194ca1ee86953855e0d2fb9396ec18636ed9
> shelve: move temporary commit creation to a separate function
Looks all good. Queued them, thanks.
> +def _commitworkingcopychanges(ui, repo, opts, tmpwctx):
> +"""Temporarily commit working copy changes before moving unshelve
commit"""
> +# Store pending changes in a commit and remember added in case a
shelve
> +# contains unknown files that are part of the pending change
> +s = repo.status()
> +addedbefore = frozenset(s.added)
> +if not (s.modified or s.added or s.removed or s.deleted):
> +return tmpwctx, addedbefore
> +ui.status(_("temporarily committing pending changes "
> +"(restore with 'hg unshelve --abort')\n"))
> +commitfunc = getcommitfunc(extra=None, interactive=False,
> + editor=False)
> +tempopts = {}
> +tempopts['message'] = "pending changes temporary commit"
> +tempopts['date'] = opts.get('date')
> +ui.quiet = True
> +node = cmdutil.commit(ui, repo, commitfunc, [], tempopts)
> +tmpwctx = repo[node]
> +return tmpwctx, addedbefore
This and the next unbalanced ui.quiet hack can be a source of future bugs.
I hope they'll be fixed by a follow-up patch.
Can you explain please? I was trying to keep the ui.quiet behavior unchanged in
this refactoring series.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH] conflicts: make spacing consistent in conflict markers
# HG changeset patch
# User Kostia Balytskyi
# Date 1479598897 28800
# Sat Nov 19 15:41:37 2016 -0800
# Node ID 5f03a63d6def1cf3c34fa7f8979c34151a9ba660
# Parent 0c3a8b6239db2c0d6a0e9ddea2266445bca2d440
conflicts: make spacing consistent in conflict markers
The way default marker template was defined before this patch,
the spacing before dash in conflict markes was dependent on
whether changeset is a tip one or not. This is a relevant part
of template:
'{ifeq(tags, "tip", "", "{tags} "}'
If revision is a tip revision with no other tags, this would
resolve to an empty string, but for revisions which are not tip
and don't have any other tags, this would resolve to a single
space string. In the end this causes weirdnesses like the ones
you can see in the affected tests.
This is a not a big deal, but double spacing may be visually
less pleasant.
Please note that test changes where commit hashes change are
the result of marking files as resolved without removing markers.
diff --git a/mercurial/filemerge.py b/mercurial/filemerge.py
--- a/mercurial/filemerge.py
+++ b/mercurial/filemerge.py
@@ -518,7 +518,8 @@ def _formatconflictmarker(repo, ctx, tem
return util.ellipsis(mark, 80 - 8)
_defaultconflictmarker = ('{node|short} '
- '{ifeq(tags, "tip", "", "{tags} ")}'
+ '{ifeq(tags, "tip", "", '
+ 'ifeq(tags, "", "", "{tags} "))}'
'{if(bookmarks, "{bookmarks} ")}'
'{ifeq(branch, "default", "", "{branch} ")}'
'- {author|user}: {desc|firstline}')
diff --git a/tests/test-commit-amend.t b/tests/test-commit-amend.t
--- a/tests/test-commit-amend.t
+++ b/tests/test-commit-amend.t
@@ -638,7 +638,7 @@ Amend a merge changeset (with renames an
(no more unresolved files)
$ hg ci -m 'merge bar'
$ hg log --config diff.git=1 -pr .
- changeset: 23:69c24fe01e35
+ changeset: 23:163cfd7219f7
tag: tip
parent: 22:30d96aeaf27b
parent: 21:1aa437659d19
@@ -657,7 +657,7 @@ Amend a merge changeset (with renames an
dd
+===
+cc
- +>>> merge rev:1aa437659d19 bar - test: aazzcc
+ +>>> merge rev:1aa437659d19 bar - test: aazzcc
diff --git a/z b/zz
rename from z
rename to zz
@@ -671,7 +671,7 @@ Amend a merge changeset (with renames an
$ HGEDITOR="sh .hg/checkeditform.sh" hg ci --amend -m 'merge bar (amend
message)' --edit
HGEDITFORM=commit.amend.merge
$ hg log --config diff.git=1 -pr .
- changeset: 24:cfa2fbef3169
+ changeset: 24:bca52d4ed186
tag: tip
parent: 22:30d96aeaf27b
parent: 21:1aa437659d19
@@ -690,7 +690,7 @@ Amend a merge changeset (with renames an
dd
+===
+cc
- +>>> merge rev:1aa437659d19 bar - test: aazzcc
+ +>>> merge rev:1aa437659d19 bar - test: aazzcc
diff --git a/z b/zz
rename from z
rename to zz
@@ -704,7 +704,7 @@ Amend a merge changeset (with renames an
$ hg mv zz z
$ hg ci --amend -m 'merge bar (undo rename)'
$ hg log --config diff.git=1 -pr .
- changeset: 26:c34de68b014c
+ changeset: 26:12594a98ca3f
tag: tip
parent: 22:30d96aeaf27b
parent: 21:1aa437659d19
@@ -723,7 +723,7 @@ Amend a merge changeset (with renames an
dd
+===
+cc
- +>>> merge rev:1aa437659d19 bar - test: aazzcc
+ +>>> merge rev:1aa437659d19 bar - test: aazzcc
$ hg debugrename z
z not renamed
@@ -740,9 +740,9 @@ Amend a merge changeset (with renames du
$ echo aa >> aaa
$ hg ci -m 'merge bar again'
$ hg log --config diff.git=1 -pr .
- changeset: 28:37d40dcef03b
+ changeset: 28:dffde028b388
tag: tip
- parent: 26:c34de68b014c
+ parent: 26:12594a98ca3f
parent: 27:4c94d5bc65f5
user:test
date:Thu Jan 01 00:00:00 1970 +
@@ -775,9 +775,9 @@ Amend a merge changeset (with renames du
$ hg mv aaa aa
$ hg ci --amend -m 'merge bar again (undo rename)'
$ hg log --config diff.git=1 -pr .
- changeset: 30:537c6d1b3633
+ changeset: 30:18e3ba160489
tag: tip
- parent: 26:c34de68b014c
+ parent: 26:12594a98ca3f
parent: 27:4c94d5bc65f5
user:test
date:Thu Jan 01 00:00:00 1970 +
@@ -817,9 +817,9 @@ Amend a merge changeset (with manifest-l
use (c)hanged version, (d)elete, or leave (u)nresolved? c
$ hg ci -m 'merge bar (with conflicts)'
$ hg log --config diff.git=1 -pr .
- changeset: 33:7afcba911942
+ changeset: 33:b4c3035e2544
tag: tip
- parent: 32:6075d69d215d
+ parent: 32:4b216ca5ba97
parent: 31:67db8847a540
user:test
date:Thu Jan 01 00:00:00 1970 +
@@ -829,9 +829,9 @@ Amend a merge changeset (with manifest-l
$ hg rm aa
$ hg ci --amend -m 'merge bar (with conflicts, amended)'
$ hg log --config diff.git=1 -pr .
- changeset: 35:376965e47ddd
+
Re: [PATCH evolve-ext] fold: disallow multiple revisions without --exact
On Fri, 2016-11-04 at 16:58 -0700, Martin von Zweigbergk via Mercurial-devel wrote: > # HG changeset patch > # User Martin von Zweigbergk > # Date 1478303512 25200 > # Fri Nov 04 16:51:52 2016 -0700 > # Node ID bb80851fe9a6e14263f0076074108556377141f9 > # Parent cb2bac3253fbd52894ffcb4719a148fe6a3da38b > fold: disallow multiple revisions without --exact > > It's very easy to think that "hg fold 4::6" will fold exactly those > revisions. In reality, it will fold those *and* any revisions between > them and the working copy. It seems very likely that users who pass > more than one revision wants to fold exactly those revisions, so let's > abort and hint that they may be looking for --exact. There was some kind of explicit reason for why originally Pierre-Yves convinced me that the current behaviour was correct. Something about how `hg fold 'draft()'` would be a common thing. I can't remember the justification anymore, something about how it's impossible to predict in advance if a revset is a single or multiple commits. I think I agree with everyone that --exact should probably just become the default again as it once was. No more `hg fold .^`, you must now do `hg fold '. + .^'` like before. Everyone seems to really want --exact and gets surprised by the magic of trying to include "." in the folded set. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext] fold: disallow multiple revisions without --exact
On Fri, Nov 4, 2016 at 6:09 PM, Kyle Lippincott wrote:
>
>
> On Fri, Nov 4, 2016 at 4:58 PM, Martin von Zweigbergk via Mercurial-devel
> wrote:
>>
>> # HG changeset patch
>> # User Martin von Zweigbergk
>> # Date 1478303512 25200
>> # Fri Nov 04 16:51:52 2016 -0700
>> # Node ID bb80851fe9a6e14263f0076074108556377141f9
>> # Parent cb2bac3253fbd52894ffcb4719a148fe6a3da38b
>> fold: disallow multiple revisions without --exact
>
>
> Per conversation on IRC, I think that the opposite would be safer: disallow
> single revisions without explicit user consent (i.e. return to the original
> behavior, according to https://www.mercurial-scm.org/wiki/EvolveUI#Why.3F).
> The situation I'm afraid of with this change is something like this (sorry
> for the mild hypotheticals involved here):
>
> If we assume a series of draft changes with A(t1), B(t1), C(t2), D(t3),
> E(t3,@),
> then a hypothetical `hg fold topic(t1)` would error, but `hg fold
> topic(t2)` would fold C,D,E.
>
> I had been thinking that `hg fold .^` would be the primary reason for the
> current non-exact (so I proposed `hg fold --prev` as equivalent to `hg fold
> .^::.`), but https://www.mercurial-scm.org/wiki/EvolveUI#Why.3F says it's
> really more like "most-recent N commits". I think requiring the user to
> count would not be ideal and it causes confusion with revision numbers, so I
> don't think that --prev would work with an argument.
>
> Instead, if we assume that most people stay tip-most in their work in
> progress chains, we could have a `hg fold --from X` as an "alias" for `hg
> fold X::.`, except that for safety reasons it should probably check that
> max(X) < .
>
> With that, merging the wip is, usually, `hg fold --from wip>`. I think --to would be unnecessary - the number of times it's useful
> would be much lower (again, if we assume most non-power-users stay tip-most,
> and power-users can be expected to use revsets properly).
I just realized that maybe --exact should be called --change. Compare
to "hg diff" and "hg status". With a single -r, they compare that
revision with wdir(). With --change, they work on that change itself,
ignoring wdir() and '.'.
Note that that's just a comment about the name of the option, not
about the default that I found confusing. But actually, also note that
"hg diff -r $rev::" resolves to a single revision, the diff is between
that revision and wdir(), but if it resolves to a range, the diff is
between the min and the max (?) of that range. So while I very much
agree with Kyle's point about risk of having the behavior depend on
how many revisions a revset resolves to, there is precedent for it.
I'm still not sure how I want this to behave, but hopefully the above
points are relevant.
>
>
>
>
>>
>>
>> It's very easy to think that "hg fold 4::6" will fold exactly those
>> revisions. In reality, it will fold those *and* any revisions between
>> them and the working copy. It seems very likely that users who pass
>> more than one revision wants to fold exactly those revisions, so let's
>> abort and hint that they may be looking for --exact.
>>
>> diff -r cb2bac3253fb -r bb80851fe9a6 hgext/evolve.py
>> --- a/hgext/evolve.py Wed Nov 02 18:56:44 2016 +0100
>> +++ b/hgext/evolve.py Fri Nov 04 16:51:52 2016 -0700
>> @@ -3115,6 +3115,11 @@
>> revs = scmutil.revrange(repo, revs)
>>
>> if not opts['exact']:
>> +if len(revs) > 1:
>> +raise error.Abort(_("cannot fold from working directory to "
>> +"more than one revision"),
>> + hint=_("did you mean to use --exact?"))
>> +
>> # Try to extend given revision starting from the working
>> directory
>> extrevs = repo.revs('(%ld::.) or (.::%ld)', revs, revs)
>> discardedrevs = [r for r in revs if r not in extrevs]
>> diff -r cb2bac3253fb -r bb80851fe9a6 tests/test-evolve.t
>> --- a/tests/test-evolve.t Wed Nov 02 18:56:44 2016 +0100
>> +++ b/tests/test-evolve.t Fri Nov 04 16:51:52 2016 -0700
>> @@ -688,7 +688,11 @@
>>$ hg fold -r 4 -r 6 --exact
>>abort: cannot fold non-linear revisions (multiple roots given)
>>[255]
>> - $ hg fold 10 1
>> + $ hg fold 4::5
>> + abort: cannot fold from working directory to more than one revision
>> + (did you mean to use --exact?)
>> + [255]
>> + $ hg fold 1
>>abort: cannot fold non-linear revisions
>>(given revisions are unrelated to parent of working directory)
>>[255]
>> diff -r cb2bac3253fb -r bb80851fe9a6 tests/test-userguide.t
>> --- a/tests/test-userguide.tWed Nov 02 18:56:44 2016 +0100
>> +++ b/tests/test-userguide.tFri Nov 04 16:51:52 2016 -0700
>> @@ -109,7 +109,7 @@
>>7:05e61aab8294 step 1
>>8:be6d5bc8e4cc step 2
>>9:35f432d9f7c1 step 3
>> - $ hg fold -d '0 0' -m 'fix bug 64' -r 7::
>> + $ hg fold -d '0 0' -m 'fix bug 64' -r 7
>>3 changesets folded
>>1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>>
Re: [PATCH] debuginstall: print compression engine support
On Fri, Nov 18, 2016 at 7:58 PM, Gregory Szorc
wrote:
> # HG changeset patch
> # User Gregory Szorc
> # Date 1479527805 28800
> # Fri Nov 18 19:56:45 2016 -0800
> # Node ID a3b70554ff2a25fa429bbf388850b982b064cb93
> # Parent 9375077f1ace71dfa2fc87a1d4eaeae8de267e20
> debuginstall: print compression engine support
>
> Since compression engines may be provided by extensions and since
> not all registered compression engines may be available to use,
> it seems useful to provide a mechanism to see the state of known
> compression engines.
>
> This commit teaches `hg debuginstall` to print info on known and
> available compression engines.
>
> diff --git a/mercurial/commands.py b/mercurial/commands.py
> --- a/mercurial/commands.py
> +++ b/mercurial/commands.py
> @@ -2579,6 +2579,16 @@ def debuginstall(ui, **opts):
> problems += 1
> fm.condwrite(err, 'extensionserror', " %s\n", err)
>
> +compengines = util.compengines._engines.values()
> +fm.write('compengines', _('checking registered compression engines
> (%s)\n'),
> + fm.formatlist(sorted(e.name() for e in compengines),
> + name='compengine', fmt='%s', sep=', '))
> +fm.write('compenginesavail', _('checking available compression
> engines '
> + '(%s)\n'),
> + fm.formatlist(sorted(e.name() for e in compengines
> + if e.available()),
> + name='compengine', fmt='%s', sep=', '))
> +
> # templates
> p = templater.templatepaths()
> fm.write('templatedirs', 'checking templates (%s)...\n', ' '.join(p))
> diff --git a/tests/test-install.t b/tests/test-install.t
> --- a/tests/test-install.t
> +++ b/tests/test-install.t
> @@ -11,6 +11,8 @@ hg debuginstall
>checking Mercurial custom build (*) (glob)
>checking module policy (*) (glob)
>checking installed modules (*mercurial)... (glob)
> + checking registered compression engines (*zlib*) (glob)
> + checking available compression engines (*zlib*) (glob)
>checking templates (*mercurial?templates)... (glob)
>checking default template (*mercurial?templates?map-cmdline.default)
> (glob)
>checking commit editor... (* -c "import sys; sys.exit(0)") (glob)
> @@ -21,6 +23,8 @@ hg debuginstall JSON
>$ hg debuginstall -Tjson | sed 's||\\|g'
>[
> {
> +"compengines": ["bz2", "bz2truncated", "none", "zlib", "zstd"],
> +"compenginesavail": ["bz2", "bz2truncated", "none", "zlib", "zstd"],
>
I'm missing some globs here. Please drop this patch. I'll send a V2 as part
of a larger series that implements support for zstd on the wire protocol :)
> "defaulttemplate": "*mercurial?templates?map-cmdline.default", (glob)
> "defaulttemplateerror": null,
> "defaulttemplatenotfound": "default",
> @@ -58,6 +62,8 @@ hg debuginstall with no username
>checking Mercurial custom build (*) (glob)
>checking module policy (*) (glob)
>checking installed modules (*mercurial)... (glob)
> + checking registered compression engines (*zlib*) (glob)
> + checking available compression engines (*zlib*) (glob)
>checking templates (*mercurial?templates)... (glob)
>checking default template (*mercurial?templates?map-cmdline.default)
> (glob)
>checking commit editor... (* -c "import sys; sys.exit(0)") (glob)
> @@ -85,6 +91,8 @@ path variables are expanded (~ is the sa
>checking Mercurial custom build (*) (glob)
>checking module policy (*) (glob)
>checking installed modules (*mercurial)... (glob)
> + checking registered compression engines (*zlib*) (glob)
> + checking available compression engines (*zlib*) (glob)
>checking templates (*mercurial?templates)... (glob)
>checking default template (*mercurial?templates?map-cmdline.default)
> (glob)
>checking commit editor... (* -c "import sys; sys.exit(0)") (glob)
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 3 of 9] chgserve: pre-import extensions
Excerpts from Yuya Nishihara's message of 2016-11-19 18:02:43 +0900: > Can we do this formally (i.e. without function wrapping and private > function calls)? chgserver.py isn't an extension now. Good idea. I'll move the logic to extensions.py ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 9] chgserver: add a top-level run method
Excerpts from Yuya Nishihara's message of 2016-11-19 18:09:18 +0900: > I'm in favor of going through dispatch.dispatch() with some special treatments > for chg, but you might be right in that it would be unnecessary complicated. > So I'll queue V2 even if it has a top-level run(). I think some dispatch logic could be helpful (reusable). chgserver also needs a ui object, a debugger could be useful, too. What do you about putting the "if-it-is-chg" condition in "_runcatch" ? hg -> run -> dispatch -> _runcatch -> _dispatch -> runcommand -> _runcommand \ \ -> chg run (current) -> chg _dispatch (proposal) The "chg _dispatch" function, if short, could be put just in dispatch.py calling chgserver functions. Otherwise it could be "chgserver._dispatch". > BTW, I have the patches to move chgserver.py to the core. If they help making > your series without the copy of chgserver.py, I'll send them out. But I guess > they wouldn't. If we can allow chg to be broken for some time, then it is fine. The copy is like an "atomictemp" to make sure the old code works (and I don't need to care about the compatibility, which is a bit tricky to maintain) during the change. > The series generally looks good to me. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH V2] help: hide command line options marked as "advanced"
Excerpts from Pierre-Yves David's message of 2016-11-19 11:05:25 +0100: > > On 11/02/2016 03:10 AM, Jun Wu wrote: > > Excerpts from Pierre-Yves David's message of 2016-11-02 02:52:36 +0100: > >> > >> On 11/02/2016 12:49 AM, Jun Wu wrote: > >>> Excerpts from Pierre-Yves David's message of 2016-11-02 00:41:03 +0100: > > On 11/01/2016 04:08 PM, Jun Wu wrote: > > # HG changeset patch > > # User Jun Wu > > # Date 1478011845 0 > > # Tue Nov 01 14:50:45 2016 + > > # Node ID 058074cf24ce30ee0bc6d6a4d91fbe35631f8e8e > > # Parent 264f00b3e5f045ac5b58d79e2a3976585f4e7739 > > # Available At https://bitbucket.org/quark-zju/hg-draft > > # hg pull https://bitbucket.org/quark-zju/hg-draft-r > > 058074cf24ce > > help: hide command line options marked as "advanced" > > > > Previously, we have keywords like "(DEPRECATED)" and "(EXPERIMENTAL)" to > > hide command line options in non-verbose help output. > > > > However, sometimes an option is neither deprecated nor experimental. > > It's > > well-tested and working, but just not designed to average users. This > > patch > > adds a keyword "(ADVANCED)" to fit in such use cases. > > > > Thanks rom1dep for the suggestion of the word "advanced". > > Do we have any candidate for this in core ? > > ^ > > It can be "other keyword candidates". > > > >>> > >>> It should be better than "(VERBOSE)". > >> > >> I'm very confused by this reply. My question is > >> > >> "Do we currently have any flag in core that could benefit from this new > >> feature?" > > > > I couldn't find candidates easily. For evolve, I think "graft -o/-O" may > > qualify. > > I'm more looking for user in core. > > hg serve have some flag only used by other script, they seems good > candidate. This could make good initial user > > --stdio for remote clients > --cmdserver MODEfor remote clients > > The --ssh related flag for clone and push/pull are probably good > candidate too (but it is less clear) > > Can you send a V3 flag --stdio and --cmdserver as advanced, I would most > probably take that. Do you mean folding the flag changes into this patch? I think that should be a separate patch (and you agreed on this on IRC). I'm not sure what needs to be changed for this patch. If I send a V3 of two patches where the second is the flag change as you described, the first patch in V3 would be identical to the current one. I'm not sure why is that better than queuing this + sending just the flag change patch. > > Cheers, > ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 2 V2] rebase: update _rebaseset inside transaction
On 11/10/2016 06:27 PM, Durham Goode wrote: # HG changeset patch # User Durham Goode # Date 1478798531 28800 # Thu Nov 10 09:22:11 2016 -0800 # Node ID 839aa67de1a6436dfc1ae29265d0bfb0c1ce3cb7 # Parent 03bc2afdfa26ad5ab057a28ac037524407ca5a92 rebase: update _rebaseset inside transaction I've taken patch 1, I'm not sure about the approach of patch 2, see below. Rebase has the concept of the _rebaseset, which is used to prevent the commits being rebased from being hidden until after the rebase is complete. Previously, the _rebaseset was being cleared at the very end of rebase, after the last transaction had already closed. This meant that the repo filteredrevs cache was not updated (since no invalidation had been triggered, since we're outside of a transaction), which meant future changelog reads saw commits as visible that should've been hidden. It looks like the main issue here is that the filteredrevs is not invalidated. The '_clearrebasesetvisibiliy' function should just clear call that cache invalidation and that would probably be enough. Using a new dedicated transaction where nothing happen for cache invalidation purpose seems a bit odd. -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH V2] help: hide command line options marked as "advanced"
On 11/02/2016 03:10 AM, Jun Wu wrote: Excerpts from Pierre-Yves David's message of 2016-11-02 02:52:36 +0100: On 11/02/2016 12:49 AM, Jun Wu wrote: Excerpts from Pierre-Yves David's message of 2016-11-02 00:41:03 +0100: On 11/01/2016 04:08 PM, Jun Wu wrote: # HG changeset patch # User Jun Wu # Date 1478011845 0 # Tue Nov 01 14:50:45 2016 + # Node ID 058074cf24ce30ee0bc6d6a4d91fbe35631f8e8e # Parent 264f00b3e5f045ac5b58d79e2a3976585f4e7739 # Available At https://bitbucket.org/quark-zju/hg-draft # hg pull https://bitbucket.org/quark-zju/hg-draft -r 058074cf24ce help: hide command line options marked as "advanced" Previously, we have keywords like "(DEPRECATED)" and "(EXPERIMENTAL)" to hide command line options in non-verbose help output. However, sometimes an option is neither deprecated nor experimental. It's well-tested and working, but just not designed to average users. This patch adds a keyword "(ADVANCED)" to fit in such use cases. Thanks rom1dep for the suggestion of the word "advanced". Do we have any candidate for this in core ? ^ It can be "other keyword candidates". It should be better than "(VERBOSE)". I'm very confused by this reply. My question is "Do we currently have any flag in core that could benefit from this new feature?" I couldn't find candidates easily. For evolve, I think "graft -o/-O" may qualify. I'm more looking for user in core. hg serve have some flag only used by other script, they seems good candidate. This could make good initial user --stdio for remote clients --cmdserver MODEfor remote clients The --ssh related flag for clone and push/pull are probably good candidate too (but it is less clear) Can you send a V3 flag --stdio and --cmdserver as advanced, I would most probably take that. Cheers, -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 1 of 5 shelve-ext] shelve: move temporary commit creation to a separate function
On Sun, 13 Nov 2016 03:39:34 -0800, Kostia Balytskyi wrote:
> # HG changeset patch
> # User Kostia Balytskyi
> # Date 1479036952 28800
> # Sun Nov 13 03:35:52 2016 -0800
> # Node ID 45dbc9a803375958310bced301227b02802372b0
> # Parent 2188194ca1ee86953855e0d2fb9396ec18636ed9
> shelve: move temporary commit creation to a separate function
Looks all good. Queued them, thanks.
> +def _commitworkingcopychanges(ui, repo, opts, tmpwctx):
> +"""Temporarily commit working copy changes before moving unshelve
> commit"""
> +# Store pending changes in a commit and remember added in case a shelve
> +# contains unknown files that are part of the pending change
> +s = repo.status()
> +addedbefore = frozenset(s.added)
> +if not (s.modified or s.added or s.removed or s.deleted):
> +return tmpwctx, addedbefore
> +ui.status(_("temporarily committing pending changes "
> +"(restore with 'hg unshelve --abort')\n"))
> +commitfunc = getcommitfunc(extra=None, interactive=False,
> + editor=False)
> +tempopts = {}
> +tempopts['message'] = "pending changes temporary commit"
> +tempopts['date'] = opts.get('date')
> +ui.quiet = True
> +node = cmdutil.commit(ui, repo, commitfunc, [], tempopts)
> +tmpwctx = repo[node]
> +return tmpwctx, addedbefore
This and the next unbalanced ui.quiet hack can be a source of future bugs.
I hope they'll be fixed by a follow-up patch.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH v2] build: include a dummy $PATH in the custom environment used by build.py
On Mon, 14 Nov 2016 16:04:46 +0100, Gábor Stefanik wrote:
> # HG changeset patch
> # User Gábor Stefanik
> # Date 1477669468 -7200
> # Fri Oct 28 17:44:28 2016 +0200
> # Node ID 1f4674a0aaeae579186ae6e5c3a022c25ab5
> # Parent 046a7e828ea63ec940ffae1089a33fae7954da2e
> build: include a dummy $PATH in the custom environment used by build.py
>
> This is required for building with pypiwin32, the pip-installable replacement
> for pywin32.
>
> diff -r 046a7e828ea6 -r 1f4674a0 setup.py
> --- a/setup.pyThu Nov 10 16:37:18 2016 -0500
> +++ b/setup.pyFri Oct 28 17:44:28 2016 +0200
> @@ -167,7 +167,8 @@
> # to not use any hgrc files and do no localization.
> env = {'HGMODULEPOLICY': 'py',
> 'HGRCPATH': '',
> - 'LANGUAGE': 'C'}
> + 'LANGUAGE': 'C',
> + 'PATH': ''} # make pypi modules that use os.environ['PATH'] happy
Looks okay. Queued, thanks.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 5 of 5 shelve-ext] shelve: move unshelve-finishing logic to a separate function
On Sun, 13 Nov 2016 03:39:38 -0800, Kostia Balytskyi wrote: > # HG changeset patch > # User Kostia Balytskyi > # Date 1478876487 28800 > # Fri Nov 11 07:01:27 2016 -0800 > # Node ID c34ee36f4e7fe6b04ea1b4e2f032e995fe65d6c5 > # Parent dce4581dcae386c3d3b420911350d176c0423520 > shelve: move unshelve-finishing logic to a separate function > > Finishing unshelve involves two steps now: > - stripping a changelog > - aborting a transaction > Obs-based shelve will not require these things, so isolating this logic > into a separate function where the normal/obs-shelve branching is > going to be implemented seems to be like a nice idea. > > Behavior-wise this change moves 'unshelvecleanup' from being between > changelog stripping and transaction abortion to being after them. > I don't think this has any negative effects. Seems fine. shelvedfile isn't a member of transaction. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 2 of 9] chgserver: add a top-level run method
On Sun, 13 Nov 2016 21:55:46 +, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu
> # Date 1479070111 0
> # Sun Nov 13 20:48:31 2016 +
> # Node ID ca7a76135db4a9b8a90665c8a42013debbdae3b7
> # Parent c04847bc1bf1804cc7d8f5e7c50a653a9526
> chgserver: add a top-level run method
>
> Currently, chg server is implemented under the "hg serve" framework, which
> is actually too later: loading extensions, loading repo etc. are the things
> chg server wants to avoid.
>
> This patch adds a "run" method, which would be the entry point of chg
> server, bypassing dispatch's code path.
>
> diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py
> --- a/mercurial/chgserver.py
> +++ b/mercurial/chgserver.py
> @@ -61,4 +61,5 @@ from . import (
> extensions,
> osutil,
> +ui as uimod,
> util,
> )
> @@ -642,2 +643,22 @@ def uisetup(ui):
> if 'CHGINTERNALMARK' in os.environ:
> del os.environ['CHGINTERNALMARK']
> +
> +def _runchgservice(args):
> +ui = uimod.ui()
> +
> +addresses = dispatch._earlygetopt(['--address'], args)
> +if not addresses:
> +raise error.Abort(_('--address is required'))
> +
> +opts = {
> +'address': addresses[-1],
> +'daemon': None,
> +'daemon_postexec': ['chdir:/'],
> +'pid_file': None,
> +}
> +
> +service = chgunixservice(ui, repo=None, opts=opts)
> +return cmdutil.service(opts, initfn=service.init, runfn=service.run)
> +
> +def run():
> +sys.exit(_runchgservice(sys.argv[1:]))
I'm in favor of going through dispatch.dispatch() with some special treatments
for chg, but you might be right in that it would be unnecessary complicated.
So I'll queue V2 even if it has a top-level run().
BTW, I have the patches to move chgserver.py to the core. If they help making
your series without the copy of chgserver.py, I'll send them out. But I guess
they wouldn't.
The series generally looks good to me.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 3 of 9] chgserve: pre-import extensions
On Sun, 13 Nov 2016 21:55:47 +, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu
> # Date 1479070477 0
> # Sun Nov 13 20:54:37 2016 +
> # Node ID 70611a6b45d51ba4bf560c2cfdb8d94e08a3dc8f
> # Parent ca7a76135db4a9b8a90665c8a42013debbdae3b7
> chgserve: pre-import extensions
>
> This patch makes chgserve pre-import extensions. It assumes that
> pre-importing extensions does not have side effects.
>
> diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py
> --- a/mercurial/chgserver.py
> +++ b/mercurial/chgserver.py
> @@ -73,4 +73,26 @@ testedwith = 'ships-with-hg-core'
> _log = commandserver.log
>
> +_preimported = {} # {(name, path): mod}
> +
> +def _preimportextensions(ui):
> +for name, path in ui.configitems('extensions'):
> +# do not pre-import disabled extensions
> +if path.startswith('!'):
> +continue
> +try:
> +mod = extensions._importext(name, path)
> +except ImportError:
> +pass
> +else:
> +_preimported[(name, path)] = mod
> +ui.debug('chg: pre-imported %s\n' % name)
> +
> +def _importext(orig, name, path=None, reportfunc=None):
> +mod = _preimported.get((name, path))
> +if mod:
> +return mod
> +else:
> +return orig(name, path, reportfunc)
> +
> def _hashlist(items):
> """return sha1 hexdigest for a list"""
> @@ -646,4 +668,5 @@ def uisetup(ui):
> def _runchgservice(args):
> ui = uimod.ui()
> +_preimportextensions(ui)
>
> addresses = dispatch._earlygetopt(['--address'], args)
> @@ -662,3 +685,4 @@ def _runchgservice(args):
>
> def run():
> +extensions.wrapfunction(extensions, '_importext', _importext)
> sys.exit(_runchgservice(sys.argv[1:]))
Can we do this formally (i.e. without function wrapping and private
function calls)? chgserver.py isn't an extension now.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH 9 of 9] chgserver: implement a simple "runcommand"
On Sun, 13 Nov 2016 21:55:53 +, Jun Wu wrote: > # HG changeset patch > # User Jun Wu > # Date 1479073486 0 > # Sun Nov 13 21:44:46 2016 + > # Node ID b923b234b9032cdd87e6519dae7fbfdd292b7b40 > # Parent 4660680374d24f7d46834b54de2fbbeec164e906 > chgserver: implement a simple "runcommand" > > Although the chgserver could just use command server's runcommand. The new > design could be very simple - no need to do ui copying etc. So let's write > it down explicitly to use the simple version. > > Future patches improving the pager area also requires a different > "runcommand" from the "commandserver" version. > > diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py > --- a/mercurial/chgserver.py > +++ b/mercurial/chgserver.py > @@ -438,4 +438,12 @@ class chgcmdserver(commandserver.server) > os.chdir(path) > > +def runcommand(self): > +"""Reads a list of \0 terminated arguments, executes and writes the > +return code to the result channel""" > +args = self._readlist() > +req = dispatch.request(args[:]) self.cin/cout/cerr should be passed for correctness. The server doesn't guarantee they are replaced with std streams by attachio. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Checking for conflict before merge
On 11/07/2016 02:48 PM, akos tajti wrote: Hi All, my problem: I have a repository with many forks. The forks are automatically merged to the blessed repo. I need to somehow check if merging a specific fork would introduce conflicts. I came up with this command sequence: * I run this in the blessed repo: hg incoming -b default --bundle /tmp/incoming.bundle FORK_URL (this will create a bundle with the incoming changesets) * then, again in the blessed repo, I run this command: hg -R /tmp/incoming.bundle merge -r tip -y --config ui.merge=internal:fail . this will show me the number of unresolved files (0, when there is no conflict) note that internal:fail will fail any file that is touched on both side. you could use internal:merge and file which can be automatically merge will be reported as successful. * so far so good. My problem is that after these commands I have to clean the repository (hg update -C . ) Is there a better solution for this. I don't really like the idea of running hg update programmatically. I'm not sure there is a better way right now. Why is running `hg update` an issue to you? (while the other command seems fine to you). Cheers, -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
