Re: [PATCH STABLE] subrepo: add test for Windows relative-ish path with drive letter

[Martin von Zweigbergk via Mercurial-devel]

On Fri, Feb 8, 2019 at 6:42 AM Yuya Nishihara  wrote:

> # HG changeset patch
> # User Yuya Nishihara 
> # Date 1549540241 -32400
> #  Thu Feb 07 20:50:41 2019 +0900
> # Branch stable
> # Node ID adf01cdceea20b5ad6dacb11dbb1d94e5055e39c
> # Parent  87a6e3c953e045d92147925fc71aad7c327fdbfd
> subrepo: add test for Windows relative-ish path with drive letter
>

Queued for stable, thanks. Sorry about the delay.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] chistedit: ensure a locale is set

[Yuya Nishihara]

On Tue, 19 Feb 2019 23:16:03 -0500, Jordi Gutiérrez Hermoso wrote:
> On Wed, 2019-02-20 at 11:22 +0900, Yuya Nishihara wrote:
> > Perhaps, we shouldn't do setlocale() until curses is actually used.
> 
> Hm, that's a good point. Move it to _chisteditmain? That's the entry
> point, I think.
> 
> Or maybe we should make our own wrapper curses module so it can be
> demandimported and use that from both chistedit and crecord?

Maybe we can add a curses setup function that calls setlocale().
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3 V2] color: change color of grep.rev label

[Yuya Nishihara]

On Tue, 19 Feb 2019 23:11:13 -0500, Jordi Gutiérrez Hermoso wrote:
> On Wed, 2019-02-20 at 11:49 +0900, Yuya Nishihara wrote:
> 
> > I've marked this as "(BC)" since this is IMHO a significant change.
> > Blue on black is unreadable on my machine.
> 
> It's kind of hard to predict what will be readable. Linux terminal
> emulators usually let you define "blue" to be whatever you want.

Yes.

> I wasn't sure if colour changes were BC, but I did put them in
> separate commits so they could easily be separately dropped. I'm okay
> with not changing the default colours and just adding more stuff to my
> config. The only part I really wanted was extra labels.

I'm not against this change. My point is that changing colors generally makes
someone unhappy, which is IMHO a behavior change.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] chistedit: ensure a locale is set

[Jordi Gutiérrez Hermoso]

On Wed, 2019-02-20 at 11:22 +0900, Yuya Nishihara wrote:
> Perhaps, we shouldn't do setlocale() until curses is actually used.

Hm, that's a good point. Move it to _chisteditmain? That's the entry
point, I think.

Or maybe we should make our own wrapper curses module so it can be
demandimported and use that from both chistedit and crecord?

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

Re: [PATCH 3 of 3 V2] color: change color of grep.rev label

[Jordi Gutiérrez Hermoso]

On Wed, 2019-02-20 at 11:49 +0900, Yuya Nishihara wrote:

> I've marked this as "(BC)" since this is IMHO a significant change.
> Blue on black is unreadable on my machine.

It's kind of hard to predict what will be readable. Linux terminal
emulators usually let you define "blue" to be whatever you want.

I wasn't sure if colour changes were BC, but I did put them in
separate commits so they could easily be separately dropped. I'm okay
with not changing the default colours and just adding more stuff to my
config. The only part I really wanted was extra labels.

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

Re: [PATCH RFC] cmdtest: add a new command that checks revset matching

[Yuya Nishihara]

On Tue, 19 Feb 2019 19:17:03 +0100, Boris FELD wrote:
> On 19/02/2019 13:52, Pulkit Goyal wrote:
> >
> >
> > On Fri, Feb 15, 2019 at 6:11 PM Raphaël Gomès
> > mailto:raphael.go...@octobus.net>> wrote:
> >
> > # HG changeset patch
> > # User Raphaël Gomès mailto:rgo...@octobus.net>>
> > # Date 1550068454 -3600
> > #      Wed Feb 13 15:34:14 2019 +0100
> > # Node ID f850e5c8547df95cd4bcb38b4ade5b5af955
> > # Parent  91701785c2c56a3ee395038488758ad2e1865265
> > # EXP-Topic cmd-test
> > cmdtest: add a new command that checks revset matching
> >
> > This command is meant to ease scripting that need to check revsets
> > validity
> > on a repository. Right now, doing such revset testing requires
> > abuse of `hg log`
> > output parsing, and is less than ideal.
> >
> > It mirrors the `test` shell builtin which is used in almost every
> > shell script
> > for branching.
> >
> > This is a first draft of this command, there is of room for
> > adjustement and evolution,
> > like fileset matching or other arguments.
> >
> >
> > You can use the `expectsize()` revset which is recently implemented
> > and pass the size as 0. So if a revset is empty, the operation will
> > succeed and you will get 0 as return value. If there are revs in the
> > revset, it will abort.
> The expectsize revset is less flexible, and provide an ambiguous return
> code when it does not match (same return as an invalid revset). The
> revset seems useful in itself, but having a clear and extensible command
> will make scripting simpler, clearer and less error-prone.

Maybe add some flag to debugrevspec command to disambiguate RepoLookupError
from the other errors?

I don't know what kind of other features the script would need, but
inspecting revset/filset syntax would belong to debugrevspec/fileset commands.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3 V2] color: change color of grep.rev label

[Yuya Nishihara]

On Mon, 18 Feb 2019 20:03:42 -0500, Jordi Gutiérrez Hermoso wrote:
> # HG changeset patch
> # User Jordi Gutiérrez Hermoso 
> # Date 1550263757 18000
> #  Fri Feb 15 15:49:17 2019 -0500
> # Node ID 4b06afa25bb124da32fcaa56d2b81405b4163b61
> # Parent  1ef5e748ebdeec679227f78179bd36bb9b3a1667
> color: change color of grep.rev label

The series has already been queued.

> GNU grep uses green for line numbers as we do, but I sometimes get a
> bit confused when I do `hg grep --diff -n` and get both line numbers
> and revisions and don't know which one is which.

I've marked this as "(BC)" since this is IMHO a significant change. Blue on
black is unreadable on my machine.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] chistedit: ensure a locale is set

[Yuya Nishihara]

On Fri, 15 Feb 2019 14:59:37 -0500, Jordi Gutiérrez Hermoso wrote:
> # HG changeset patch
> # User Jordi Gutiérrez Hermoso 
> # Date 1550260567 18000
> #  Fri Feb 15 14:56:07 2019 -0500
> # Node ID 611f94479e62c720f7f90f3a58137e97aa600fcb
> # Parent  a22321f2b1ee18ea09a70fee9e524d2f0298
> chistedit: ensure a locale is set
> 
> My paternal surname was showing incorrectly without this fix.
> 
> diff --git a/hgext/histedit.py b/hgext/histedit.py
> --- a/hgext/histedit.py
> +++ b/hgext/histedit.py
> @@ -948,6 +948,12 @@ def findoutgoing(ui, repo, remote=None, 
>  # Curses Support
>  try:
>  import curses
> +
> +# Curses requires setting the locale or it will default to the C
> +# locale. This sets the locale to the user's default system
> +# locale.
> +import locale
> +locale.setlocale(locale.LC_ALL, u'')

Just FYI, this will make the issue5261 more likely happen since extension
modules aren't demand-loaded.

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

Perhaps, we shouldn't do setlocale() until curses is actually used.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@41718: 2 new changesets

[Mercurial Commits]

2 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/9060af281be7
changeset:   41717:9060af281be7
user:Georges Racinet 
date:Mon Feb 04 19:46:57 2019 +0100
summary: rust: itering less on MissingAncestors.bases for max()

https://www.mercurial-scm.org/repo/hg/rev/a87ca1d7e61d
changeset:   41718:a87ca1d7e61d
bookmark:@
tag: tip
user:Pulkit Goyal 
date:Mon Feb 11 16:34:48 2019 +0300
summary: branchmap: improve doc about BranchMapCache class

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

Re: rust hg status

[Valentin Gatien-Baron]

On Tue, Feb 19, 2019 at 10:46 AM Augie Fackler  wrote:

> On Fri, Feb 15, 2019 at 02:39:44PM -0500, Valentin Gatien-Baron wrote:
> > Hello,
> >
> > I wrote a fraction of hg status in rust, just the minimum needed to
> > compare current revision and working copy with few of the flags and
> > config settings supported. As you can imagine, the goal was better
> > performance.  Before trying to upstream bits of this, I figured I'd
> > check there's interest for this change in particular, or this kind
> > of changes in general (I suspect rust would bring significant
> > improvements to hg cat or hg files). The rest of this mail is more
> > details.
>
> This sounds _very_ promising and I'd love to see what you've got!
>

Cool!
Seeing my mail again, it's perhaps not clearly said that what I have and
what I timed below is a fully rust exe that implements a fraction of hg
status, not a change to python hg that uses big chunks of rust some
fraction of the time. Though it seems that upstreaming would take the
latter approach, at least to start with.


>
> >
> > While the implementation doesn't handle every uncommon situation right
> > and could use some serious cleanup, it's an interesting performance
> > improvement. In a repository with 100k tracked files and 500k ignored
> > files, in the best case and measuring on a good machine:
> >
> > - hg-rs st takes ~50ms
> > - hg-rs st -mard takes ~14ms
> > - hg-rs st -u takes ~39ms
> >
> > By contrast, hg+chg+fsmonitor's best case is 110ms regardless of
> > flags. Without fsmonitor, we're talking about 2.4s for hg st or hg st
> > -u, and 400ms for hg st -mard. As a baseline, hg st --syntax-error
> > takes 12ms.
>
> Fascinating! Are you using re2 or Python's built-in re?
>

Definitely using re2. If I disable re2, the full status goes from 2.4s to
5.7s. I didn't say how the rust implementation differs from the python
version, but using rust+re2 is not enough to get to 40ms for finding
unknown files. In addition to optimizations to the hgignore handling
(mostly special treatment of globs that can match exactly one file), and
parallelism, and not pointlessly lstat'ing untracked files in filesystems
that provide the filetype in readdir, there's a cache that holds a list of
"this directory is known to have no untracked files assuming it has this
timestamp, and the hgignore is bla and the dirstate is bla", which usually
shortcuts the listing of untracked files in most directories, and thus
shortcuts applying the hgignore on such files.
Though even when the cache fails to help, like when the hgignore changes,
rust status takes 300ms (and it's quite plausible there's room for
improvement here, I stopped optimizing when it felt like a good enough
replacement).


>
> >
> > A ratio of x2 compared with fsmonitor+chg is nice, but while neither
> > best case is what you get all the time, fsmonitor degrades pretty
> > badly, oftentimes in hard to understand ways, making for an
> > unpredictable experience that is frequently bad.
> > Say you change the hgignore, the rust version will take 300ms, the
> > fsmonitor version will take 4.4s (I think 2s timeout + 2.4s regular
> > status).
> > Say you remove a directory at the root of the repository, 50ms rust
> > vs 4.4s fsmonitor.
> > Say you haven't used a particular share in some time, you may well see
> > 1s rust vs 4.4s fsmonitor.
> >
> > So I think there's a lot of value in having status without fsmonitor
> > going much faster:
> > - increase significantly the scale at which fsmonitor is needed
> > - improve the bad cases of fsmonitor (or even the fast path depending
> > on how things are made to work together)
> >
> > Regards,
> >
> > Valentin Gatien-Baron
>
> > ___
> > 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

D5966: test: stabilize test-run-tests.t output

[lothiraldan (Boris Feld)]

lothiraldan added inline comments.

INLINE COMMENTS

> durin42 wrote in test-run-tests.t:1177
> I don't feel strongly, let's just make it permissive so the test passes on 
> both fast and slow systems.

I think it's the case, the first part of the regex `\d+` will match any amount 
of seconds and the remaining part `\.\d{3,4}` should match as long the 
precision doesn't change.

REPOSITORY
  rHG Mercurial

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

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

D5960: test: stabilize test-remotefilelog-bgprefetch.t flaky output

[lothiraldan (Boris Feld)]

lothiraldan added a comment.


  In https://phab.mercurial-scm.org/D5960#87357, @durin42 wrote:
  
  > In https://phab.mercurial-scm.org/D5960#87330, @lothiraldan wrote:
  >
  > > In https://phab.mercurial-scm.org/D5960#87251, @durin42 wrote:
  > >
  > > > Huh. That's strictly a bug, as `debugwaitonrepack` should actually be 
waiting.
  > >
  > >
  > > I've created a ticket to track it: https://phab.mercurial-scm.org/D5960
  > >
  > > Do you have any idea what could be happening?
  >
  >
  > I've never seen this failure, so I'm suspicious of your test environment. 
Is there anything exotic, perhaps at the filesystem level?
  
  
  I'm using BTRFS localy, I reproduced inside a mounted Docker container 
locally. On the CI side, the slave seems to run with an OverlayFS disk.

REPOSITORY
  rHG Mercurial

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

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

Re: [PATCH RFC] cmdtest: add a new command that checks revset matching

[Boris FELD]

On 19/02/2019 13:52, Pulkit Goyal wrote:
>
>
> On Fri, Feb 15, 2019 at 6:11 PM Raphaël Gomès
> mailto:raphael.go...@octobus.net>> wrote:
>
> # HG changeset patch
> # User Raphaël Gomès mailto:rgo...@octobus.net>>
> # Date 1550068454 -3600
> #      Wed Feb 13 15:34:14 2019 +0100
> # Node ID f850e5c8547df95cd4bcb38b4ade5b5af955
> # Parent  91701785c2c56a3ee395038488758ad2e1865265
> # EXP-Topic cmd-test
> cmdtest: add a new command that checks revset matching
>
> This command is meant to ease scripting that need to check revsets
> validity
> on a repository. Right now, doing such revset testing requires
> abuse of `hg log`
> output parsing, and is less than ideal.
>
> It mirrors the `test` shell builtin which is used in almost every
> shell script
> for branching.
>
> This is a first draft of this command, there is of room for
> adjustement and evolution,
> like fileset matching or other arguments.
>
>
> You can use the `expectsize()` revset which is recently implemented
> and pass the size as 0. So if a revset is empty, the operation will
> succeed and you will get 0 as return value. If there are revs in the
> revset, it will abort.
The expectsize revset is less flexible, and provide an ambiguous return
code when it does not match (same return as an invalid revset). The
revset seems useful in itself, but having a clear and extensible command
will make scripting simpler, clearer and less error-prone.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D5792: uncommit: added interactive mode(issue6062)

[taapas1128 (Taapas Agrawal)]

taapas1128 added a comment.


  @durin42 please review this whenever you are free.

REPOSITORY
  rHG Mercurial

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

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

D5983: debugpathcopies: sort output so it's deterministic

[martinvonz (Martin von Zweigbergk)]

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

REPOSITORY
  rHG Mercurial

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

AFFECTED FILES
  mercurial/debugcommands.py

CHANGE DETAILS

diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
--- a/mercurial/debugcommands.py
+++ b/mercurial/debugcommands.py
@@ -1815,7 +1815,7 @@
 ctx1 = scmutil.revsingle(repo, rev1)
 ctx2 = scmutil.revsingle(repo, rev2)
 m = scmutil.match(ctx1, pats, opts)
-for dst, src in copies.pathcopies(ctx1, ctx2, m).items():
+for dst, src in sorted(copies.pathcopies(ctx1, ctx2, m).items()):
 ui.write('%s -> %s\n' % (src, dst))
 
 @command('debugpeer', [], _('PATH'), norepo=True)



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

Re: rust hg status

[Augie Fackler]

On Fri, Feb 15, 2019 at 02:39:44PM -0500, Valentin Gatien-Baron wrote:
> Hello,
>
> I wrote a fraction of hg status in rust, just the minimum needed to
> compare current revision and working copy with few of the flags and
> config settings supported. As you can imagine, the goal was better
> performance.  Before trying to upstream bits of this, I figured I'd
> check there's interest for this change in particular, or this kind
> of changes in general (I suspect rust would bring significant
> improvements to hg cat or hg files). The rest of this mail is more
> details.

This sounds _very_ promising and I'd love to see what you've got!

>
> While the implementation doesn't handle every uncommon situation right
> and could use some serious cleanup, it's an interesting performance
> improvement. In a repository with 100k tracked files and 500k ignored
> files, in the best case and measuring on a good machine:
>
> - hg-rs st takes ~50ms
> - hg-rs st -mard takes ~14ms
> - hg-rs st -u takes ~39ms
>
> By contrast, hg+chg+fsmonitor's best case is 110ms regardless of
> flags. Without fsmonitor, we're talking about 2.4s for hg st or hg st
> -u, and 400ms for hg st -mard. As a baseline, hg st --syntax-error
> takes 12ms.

Fascinating! Are you using re2 or Python's built-in re?

>
> A ratio of x2 compared with fsmonitor+chg is nice, but while neither
> best case is what you get all the time, fsmonitor degrades pretty
> badly, oftentimes in hard to understand ways, making for an
> unpredictable experience that is frequently bad.
> Say you change the hgignore, the rust version will take 300ms, the
> fsmonitor version will take 4.4s (I think 2s timeout + 2.4s regular
> status).
> Say you remove a directory at the root of the repository, 50ms rust
> vs 4.4s fsmonitor.
> Say you haven't used a particular share in some time, you may well see
> 1s rust vs 4.4s fsmonitor.
>
> So I think there's a lot of value in having status without fsmonitor
> going much faster:
> - increase significantly the scale at which fsmonitor is needed
> - improve the bad cases of fsmonitor (or even the fast path depending
> on how things are made to work together)
>
> Regards,
>
> Valentin Gatien-Baron

> ___
> 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: D5514: test: change test's diff generation to use mdiff for nicer output

[Sangeet Kumar Mishra]

Apologies, I didn't run the tests after the latest addition. 

On Tue, Feb 19, 2019, 20:39 durin42 (Augie Fackler) <
phabrica...@mercurial-scm.org wrote:

> durin42 added a comment.
>
>
>   Even with my in-flight fixes, I can't get this to use the
> non-unified_diff codepath. Can you test again?
>
>   https://bitbucket.org/snippets/durin42/nejj94 has my in-flight fixes,
> but you may find it challenging to apply (the test output in the commit
> message confuses the patch parser). Hopefully that helps...
>
> INLINE COMMENTS
>
> > run-tests.py:80
> > +_diff = mdiff.new_diff
> > +except except (ImportError, AttributeError):
> > +print("Falling back to unified_diff")
>
> In the future please *run tests* before requesting another round of
> review: this is a trivial syntax error and proves you didn't try running
> tests.
>
> REPOSITORY
>   rHG Mercurial
>
> REVISION DETAIL
>   https://phab.mercurial-scm.org/D5514
>
> To: sangeet259, #hg-reviewers, durin42
> Cc: pulkit, durin42, mercurial-devel
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 7 of 7] tests: bulk changes to avoid whitespace errors of check-code.py

[Augie Fackler]

On Mon, Feb 18, 2019 at 02:19:30AM +0900, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori 
> # Date 1550417245 -32400
> #  Mon Feb 18 00:27:25 2019 +0900
> # Node ID 2f6a1d093864a07557a439d6c8fa0f583bc6a4ce
> # Parent  4f1714df74136e8b46a35810e2e46a7d25b243a8
> # Available At https://bitbucket.org/foozy/mercurial-wip
> #  hg pull https://bitbucket.org/foozy/mercurial-wip -r 
> 2f6a1d093864
> # EXP-Topic tests-fix-check-code-errors
> tests: bulk changes to avoid whitespace errors of check-code.py

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

Re: [PATCH] chistedit: ensure a locale is set

[Augie Fackler]

> On Feb 19, 2019, at 10:33, Jordi Gutiérrez Hermoso  wrote:
> 
> On Tue, 2019-02-19 at 10:29 -0500, Augie Fackler wrote:
>> On Fri, Feb 15, 2019 at 02:59:37PM -0500, Jordi Gutiérrez Hermoso wrote:
>>> # HG changeset patch
>>> # User Jordi Gutiérrez Hermoso 
>>> # Date 1550260567 18000
>>> #  Fri Feb 15 14:56:07 2019 -0500
>>> # Node ID 611f94479e62c720f7f90f3a58137e97aa600fcb
>>> # Parent  a22321f2b1ee18ea09a70fee9e524d2f0298
>>> chistedit: ensure a locale is set
>> 
>> u, if you say so
>> 
>> queued
> 
> If it's any reassurance, crecord does this too, and you haven't seen
> weirndess when picking hunks, have you?

I live a 7-bit-clean lifestyle. ;)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] chistedit: ensure a locale is set

[Jordi Gutiérrez Hermoso]

On Tue, 2019-02-19 at 10:29 -0500, Augie Fackler wrote:
> On Fri, Feb 15, 2019 at 02:59:37PM -0500, Jordi Gutiérrez Hermoso wrote:
> > # HG changeset patch
> > # User Jordi Gutiérrez Hermoso 
> > # Date 1550260567 18000
> > #  Fri Feb 15 14:56:07 2019 -0500
> > # Node ID 611f94479e62c720f7f90f3a58137e97aa600fcb
> > # Parent  a22321f2b1ee18ea09a70fee9e524d2f0298
> > chistedit: ensure a locale is set
> 
> u, if you say so
> 
> queued

If it's any reassurance, crecord does this too, and you haven't seen
weirndess when picking hunks, have you?

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

Re: [PATCH 2 of 2] tests: conditionalize msys path mangling in test-bundle.t

[Augie Fackler]

On Sat, Feb 16, 2019 at 10:58:50PM -0500, Matt Harbison wrote:
> # HG changeset patch
> # User Matt Harbison 
> # Date 1550372638 18000
> #  Sat Feb 16 22:03:58 2019 -0500
> # Node ID 99ed0ac693fb7c6045ecf69cf17909e8dc48a85a
> # Parent  f1646b79dafcca63a5681713da6e7b9db5d71afa
> tests: conditionalize msys path mangling in test-bundle.t

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

Re: [PATCH] chistedit: ensure a locale is set

[Augie Fackler]

On Fri, Feb 15, 2019 at 02:59:37PM -0500, Jordi Gutiérrez Hermoso wrote:
> # HG changeset patch
> # User Jordi Gutiérrez Hermoso 
> # Date 1550260567 18000
> #  Fri Feb 15 14:56:07 2019 -0500
> # Node ID 611f94479e62c720f7f90f3a58137e97aa600fcb
> # Parent  a22321f2b1ee18ea09a70fee9e524d2f0298
> chistedit: ensure a locale is set

u, if you say so

queued

>
> My paternal surname was showing incorrectly without this fix.
>
> diff --git a/hgext/histedit.py b/hgext/histedit.py
> --- a/hgext/histedit.py
> +++ b/hgext/histedit.py
> @@ -948,6 +948,12 @@ def findoutgoing(ui, repo, remote=None,
>  # Curses Support
>  try:
>  import curses
> +
> +# Curses requires setting the locale or it will default to the C
> +# locale. This sets the locale to the user's default system
> +# locale.
> +import locale
> +locale.setlocale(locale.LC_ALL, u'')
>  except ImportError:
>  curses = None
>
> ___
> 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: Auto-formatting code with black - object now if you have a strong opinion

[Augie Fackler]

On Wed, Feb 13, 2019 at 10:33:15AM +0100, Boris FELD wrote:
> On 01/12/2018 02:35, Matt Harbison wrote:
> > On Fri, 30 Nov 2018 07:25:04 -0500, Boris FELD
> >  wrote:
> >
> >> I think using automatic formatting is a great idea and we should move
> >> forward with this plan. Black seems a good option. I share other's
> >> concerns about the formatting of import. I also wonder if this also
> >> applies to list and dict formatting that we tend to express with one
> >> value per line for clarity.
> >
> > It looks like yes, unfortunately, if it fits on one line:
> >
> > diff --git a/hgext/lfs/blobstore.py b/hgext/lfs/blobstore.py
> > --- a/hgext/lfs/blobstore.py
> > +++ b/hgext/lfs/blobstore.py
> > @@ -289,50 +289,47 @@ class _gitlfsremote(object):
> >  Return decoded JSON object like {'objects': [{'oid': '',
> > 'size': 1}]}
> >  See
> > https://github.com/git-lfs/git-lfs/blob/master/docs/api/batch.md
> >  """
> > -    objects = [{'oid': p.oid(), 'size': p.size()} for p in pointers]
> > -    requestdata = json.dumps({
> > -    'objects': objects,
> > -    'operation': action,
> > -    })
> > -    url = '%s/objects/batch' % self.baseurl
> > +    objects = [{"oid": p.oid(), "size": p.size()} for p in pointers]
> > +    requestdata = json.dumps({"objects": objects, "operation":
> > action})
> > +    url = "%s/objects/batch" % self.baseurl
> >  batchreq = util.urlreq.request(url, data=requestdata)
> > ...
>
> We have been discussing with the Black author about how we could handle
> those cases and we found a `hack` which is adding an empty comment on
> the first line of a list, dict, multi-line construction:

If you're talking to Łukasz, could you float the way clang-format
works by him? That is, if a trailing comma is present in the literal
it's formatted one element per line, but if there's no trailing comma
it's formatted compactly. I've found that to be a good tradeoff. It'd
also make our import blocks format correctly without modification.

>
> For example:
>
> requestdata = json.dumps({
>     #
>     'objects': objects,
>     'operation': action,
>
> })

I...guess I can live with that. Begrudgingly.

>
> Would get transformed into:
>
> requestdata = json.dumps(
>     {
>     #
>     "objects": objects,
>     "operation": action,
>     }
> )
>
> which is then stable.
>
> > I'm also concerned about stuff like this, which seems far less
> > readable than the original (especially the conditional):
> >
> > diff --git a/hgext/relink.py b/hgext/relink.py
> > --- a/hgext/relink.py
> > +++ b/hgext/relink.py
> > @@ -56,29 +50,32 @@ def relink(ui, repo, origin=None, **opts
> >  command is running. (Both repositories will be locked against
> >  writes.)
> >  """
> > -    if (not util.safehasattr(util, 'samefile') or
> > -    not util.safehasattr(util, 'samedevice')):
> > -    raise error.Abort(_('hardlinks are not supported on this
> > system'))
> > -    src = hg.repository(repo.baseui, ui.expandpath(origin or
> > 'default-relink',
> > -  origin or 'default'))
> > -    ui.status(_('relinking %s to %s\n') % (src.store.path,
> > repo.store.path))
> > +    if not util.safehasattr(util, "samefile") or not util.safehasattr(
> > +    util, "samedevice"
> > +    ):
> > +    raise error.Abort(_("hardlinks are not supported on this
> > system"))
> > +    src = hg.repository(
> > +    repo.baseui, ui.expandpath(origin or "default-relink", origin
> > or "default")
> > +    )
> > +    ui.status(_("relinking %s to %s\n") % (src.store.path,
> > repo.store.path))
> >  if repo.root == src.root:
> Black output is not final yet, Black author wants to have the
> possibility to make bugfixes. This particular example might be a bug
> that could be solved. It could also be solved by extracting parameters
> into variables.
> >
> > This was actually in the first file that I randomly sampled.  I think
> > there were a few more instances like this, but don't feel motivated to
> > find them now.  There were a bunch of lines (in lfs anyway) that were
> > flattened out, and were more readable.  But that was before I saw that
> > the default formatting is 88 columns.  So maybe allowing longer lines
> > would help?  (At the cost of possibly rolling up more lists and dicts
> > into a single line.)
> >
> > I'm not adamantly opposed, and the idea of combining version control
> > and tooling to enforce a format is intriguing.  But FWIW, I'm not
> > thrilled with the result of this.
> > ___
> > 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

rust hg status

[Valentin Gatien-Baron]

Hello,

I wrote a fraction of hg status in rust, just the minimum needed to
compare current revision and working copy with few of the flags and
config settings supported. As you can imagine, the goal was better
performance.  Before trying to upstream bits of this, I figured I'd
check there's interest for this change in particular, or this kind
of changes in general (I suspect rust would bring significant
improvements to hg cat or hg files). The rest of this mail is more
details.

While the implementation doesn't handle every uncommon situation right
and could use some serious cleanup, it's an interesting performance
improvement. In a repository with 100k tracked files and 500k ignored
files, in the best case and measuring on a good machine:

- hg-rs st takes ~50ms
- hg-rs st -mard takes ~14ms
- hg-rs st -u takes ~39ms

By contrast, hg+chg+fsmonitor's best case is 110ms regardless of
flags. Without fsmonitor, we're talking about 2.4s for hg st or hg st
-u, and 400ms for hg st -mard. As a baseline, hg st --syntax-error
takes 12ms.

A ratio of x2 compared with fsmonitor+chg is nice, but while neither
best case is what you get all the time, fsmonitor degrades pretty
badly, oftentimes in hard to understand ways, making for an
unpredictable experience that is frequently bad.
Say you change the hgignore, the rust version will take 300ms, the
fsmonitor version will take 4.4s (I think 2s timeout + 2.4s regular
status).
Say you remove a directory at the root of the repository, 50ms rust
vs 4.4s fsmonitor.
Say you haven't used a particular share in some time, you may well see
1s rust vs 4.4s fsmonitor.

So I think there's a lot of value in having status without fsmonitor
going much faster:
- increase significantly the scale at which fsmonitor is needed
- improve the bad cases of fsmonitor (or even the fast path depending
on how things are made to work together)

Regards,

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

[Bug 6084] New: `hg merge` can loose file renames

[mercurial-bugs]

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

Bug ID: 6084
   Summary: `hg merge` can loose file renames
   Product: Mercurial
   Version: 4.8
  Hardware: PC
OS: Linux
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: 7895pul...@gmail.com
CC: mercurial-devel@mercurial-scm.org

I can reproduce this by the following steps:

```
$ hg init temprepo
$ cd temprepo/
$ echo a > a
$ hg ci -Aqm 'added a'
$ echo b > b
$ hg ci -Aqm 'added b'  
$ echo c > c
$ hg ci -Aqm 'added c'  
$ hg prev
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
[1] added b
$ hg mv b d
$ hg diff
diff --git a/b b/d
rename from b
rename to d
$ hg ci -m "moved b to d"   
created new head
(consider using topic for lightweight branches. See 'hg help topic')
$ hg work
@  799c moved b to d
| o  62bd added c
|/
o  a1fc added b
o  a5ea added a
$ hg up 62bd
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg work
o  799c moved b to d
| @  62bd added c
|/
o  a1fc added b
o  a5ea added a
$ hg merge
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg diff
diff --git a/b b/b
deleted file mode 100644
--- a/b
+++ /dev/null
@@ -1,1 +0,0 @@
-b
diff --git a/d b/d
new file mode 100644
--- /dev/null
+++ b/d
@@ -0,0 +1,1 @@
+b
pulkit@pulkit-nix:~/repo/temprepo$ hg status
M d
R b
# The repository is in an unfinished *merge* state.

# To continue:hg commit
# To abort:   hg merge --abort

$ hg config experimental.copytrace
$
```

As it can be seen, file rename is lost after merging.

This is a quite important issue because when using merges, we merge a user
branch into default and the moves in user branch does not come to default
branch.

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

D5981: tests: drop a few unnecessary "(glob)"

[mharbison72 (Matt Harbison)]

mharbison72 added a comment.


  In https://phab.mercurial-scm.org/D5981#87343, @martinvonz wrote:
  
  > In https://phab.mercurial-scm.org/D5981#87341, @mharbison72 wrote:
  >
  > > The tests run clean with this.
  > >
  > > But I'm a bit confused.  The test harness has been doing '\' -> '/' 
conversion without (glob) now for a little over a year, and it complains if 
there's a trailing (glob) and no '\' -> '/' conversion.  That's not been 
happening here, and made me suspicious.  These globs predate that functionality 
slightly, so I'm not sure the meaning of the referenced commit (which seems to 
say nothing will change because ui.slash is set).
  >
  >
  > You're right, and even if I go back to 
https://phab.mercurial-scm.org/rHGbdcaf612e75a08f20257076845510353a448b57d 
(where you added these globs), it seems like it should have been converted to 
slashes already there (because the test runner set ui.slash back then, too, and 
the code seemed to respect that). Do you have time to go back and see if the 
globbing was never needed?
  
  
  It was needed.  In fact the test runner itself added it on Windows.  (There's 
logic in there to add it to the output if changing '\' to '/' results in a 
match.)  I bisected the `HGPLAIN=1 hg status --cwd a` test back to 
https://phab.mercurial-scm.org/rHG7e3b145f824793ccdb5caf4f13570d4f25ab0164, 
where the trail went cold- it fails there too where it was added.  Backing up 
one more and reverting the test to that also fails, so it wasn't a code change 
there causing it.
  
  (As an aside, it would be awesome if bisect accepted a --force to ignore the 
dirty working copy check.  Then I could take out the globs, and see where it 
started working without having to manually update to each candidate.  I guess 
the question then is whether to merge the dirty changes on each update, or just 
revert to the dirty changes as-is.  I guess I'd lean towards the latter for 
automated bisection.)
  
  > Maybe the "no complaining from test harness" is because these lines contain 
a "?", which is a glob character, so maybe it doesn't warn then?
  
  Strangely, no.  I added a (glob) to a random status test that listed only the 
file with an unknown status in 
https://phab.mercurial-scm.org/rHG37a0ad669051ab70b89aaf669a7c277a908cf4b4 and 
https://phab.mercurial-scm.org/rHG37b33c34bf4f890857b5e8728febbc82a99368a5, and 
they both took away the stray (glob).
  
  >> To be clear, these paths are still being printed with '\', and the test 
harness is accommodating that.  But I'm not sure if that's what you intended.
  > 
  > Yes, I hope that my recent changes has made it so more commands, not fewer, 
print paths in the native form.

REPOSITORY
  rHG Mercurial

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

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

D5966: test: stabilize test-run-tests.t output

[durin42 (Augie Fackler)]

durin42 added inline comments.

INLINE COMMENTS

> lothiraldan wrote in test-run-tests.t:1177
> Yes we could.
> 
> I think the regex was previously `{4,5}` for two reasons:
> 
> - We expected the duration to be less than 10 seconds.
> 
> - The precision of the number was 3 digits or 4 digits after the dot 
> depending if we used json or simplejson for dumping the data.
> 
> Right now, it seems that `run-tests.py` itself is limitation the precision of 
> the digits.
> 
> So we can either drop the {3,4} as we should have a stable number of digits 
> after the dot, and anyone changing the precision of times in `run-tests.py` 
> will have a diff in this test.
> 
> Or we make it more permissive so we don't need to bother about updating it 
> later.
> 
> I don't have a strong opinion about either, what do you think we should do?

I don't feel strongly, let's just make it permissive so the test passes on both 
fast and slow systems.

REPOSITORY
  rHG Mercurial

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

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

D5960: test: stabilize test-remotefilelog-bgprefetch.t flaky output

[durin42 (Augie Fackler)]

durin42 added a comment.


  In https://phab.mercurial-scm.org/D5960#87330, @lothiraldan wrote:
  
  > In https://phab.mercurial-scm.org/D5960#87251, @durin42 wrote:
  >
  > > Huh. That's strictly a bug, as `debugwaitonrepack` should actually be 
waiting.
  >
  >
  > I've created a ticket to track it: https://phab.mercurial-scm.org/D5960
  >
  > Do you have any idea what could be happening?
  
  
  I've never seen this failure, so I'm suspicious of your test environment. Is 
there anything exotic, perhaps at the filesystem level?

REPOSITORY
  rHG Mercurial

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

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

D5514: test: change test's diff generation to use mdiff for nicer output

[durin42 (Augie Fackler)]

durin42 added a comment.


  Even with my in-flight fixes, I can't get this to use the non-unified_diff 
codepath. Can you test again?
  
  https://bitbucket.org/snippets/durin42/nejj94 has my in-flight fixes, but you 
may find it challenging to apply (the test output in the commit message 
confuses the patch parser). Hopefully that helps...

INLINE COMMENTS

> run-tests.py:80
> +_diff = mdiff.new_diff
> +except except (ImportError, AttributeError):
> +print("Falling back to unified_diff")

In the future please *run tests* before requesting another round of review: 
this is a trivial syntax error and proves you didn't try running tests.

REPOSITORY
  rHG Mercurial

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

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

D5514: test: change test's diff generation to use mdiff for nicer output

[durin42 (Augie Fackler)]

durin42 added a comment.


  I've done some cleanups (dropped an unused import, copyedited the commit 
message a bit) and should push this soon. Thanks!

REPOSITORY
  rHG Mercurial

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

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

Re: [PATCH V2] templatekw: add a {negrev} keyword

[Yuya Nishihara]

On Mon, 18 Feb 2019 14:25:42 -0500, Jordi Gutiérrez Hermoso wrote:
> On Mon, 2019-02-18 at 22:29 +0900, Yuya Nishihara wrote:
> > The word "negative revision" isn't correct, 
> 
> Why do you think so? The full phrase is "negative revision number",
> isn't it?

I don't think {negrev} is a revision number. It's merely an offset from
the tip. The help says "A plain integer is treated as a revision number.
Negative integers are treated as sequential offsets from the tip."

> > There are two weird cases:
> > 
> >  -r 'wdir()' => not negative
> >  -r null => unsupported negative integer (out of range)
> > 
> > Maybe return None for these?
> 
> Oh, these are also broken for the normal {rev} template keyword.

No. {rev} returns a valid revision number. 'rev(-1)' and 'rev(2147483647)'
work if these revisions are populated by e.g. 'null:wdir() & ...'.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] negrev: return empty for wdir() and nullrev

[Yuya Nishihara]

On Mon, 18 Feb 2019 23:48:00 -0500, Jordi Gutiérrez Hermoso wrote:
> # HG changeset patch
> # User Jordi Gutiérrez Hermoso 
> # Date 1550551420 18000
> #  Mon Feb 18 23:43:40 2019 -0500
> # Node ID 379d5bef7d3601d43c5d7d4c4c39d7014bc71208
> # Parent  37b33c34bf4f890857b5e8728febbc82a99368a5
> negrev: return empty for wdir() and nullrev

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

Re: [PATCH RFC] cmdtest: add a new command that checks revset matching

[Pulkit Goyal]

On Fri, Feb 15, 2019 at 6:11 PM Raphaël Gomès 
wrote:

> # HG changeset patch
> # User Raphaël Gomès 
> # Date 1550068454 -3600
> #  Wed Feb 13 15:34:14 2019 +0100
> # Node ID f850e5c8547df95cd4bcb38b4ade5b5af955
> # Parent  91701785c2c56a3ee395038488758ad2e1865265
> # EXP-Topic cmd-test
> cmdtest: add a new command that checks revset matching
>
> This command is meant to ease scripting that need to check revsets validity
> on a repository. Right now, doing such revset testing requires abuse of
> `hg log`
> output parsing, and is less than ideal.
>
> It mirrors the `test` shell builtin which is used in almost every shell
> script
> for branching.
>
> This is a first draft of this command, there is of room for adjustement
> and evolution,
> like fileset matching or other arguments.
>

You can use the `expectsize()` revset which is recently implemented and
pass the size as 0. So if a revset is empty, the operation will succeed and
you will get 0 as return value. If there are revs in the revset, it will
abort.

https://phab.mercurial-scm.org/rHG8185c8abce87b305920bca9ec26ccbfd11279436

>
> diff -r 91701785c2c5 -r f850e5c85eee mercurial/commands.py
> --- a/mercurial/commands.py Mon Feb 11 11:18:37 2019 -0500
> +++ b/mercurial/commands.py Wed Feb 13 15:34:14 2019 +0100
> @@ -5942,6 +5942,22 @@
>  fm.plain('\n')
>  fm.end()
>
> +@command('test', [], _('REVS'), helpcategory=command.CATEGORY_MISC)
> +def cmdtest(ui, repo, *revs):
> +"""check if revset match anything
> +
> +Helper command that mirrors the shell builtin of the same name.
> +If revset match anything, exits with 0, else exits with 1.
> +"""
> +# XXX if `hg test` is used in scripting, using user aliases may
> +# XXX be a security issue.
> +revs = scmutil.revrange(repo, revs)
> +
> +if revs:
> +return 0
> +else:
> +return 1
> +
>  @command('tip',
>  [('p', 'patch', None, _('show patch')),
>  ('g', 'git', None, _('use git extended diff format')),
> diff -r 91701785c2c5 -r f850e5c85eee tests/test-cmdtest.t
> --- /dev/null   Thu Jan 01 00:00:00 1970 +
> +++ b/tests/test-cmdtest.t  Wed Feb 13 15:34:14 2019 +0100
> @@ -0,0 +1,31 @@
> +
> +Testing of the `hg test` command
> +
> +
> +Initial setup
> +=
> +
> +  $ hg init cmdtest
> +  $ cd cmdtest
> +  $ hg debugbuilddag .+10
> +
> +
> +Basic expression
> +
> +
> +Simple successful
> +
> +  $ hg test 0
> +
> +Simple empty revset
> +
> +  $ hg test "(0 and 1)"
> +  [1]
> +
> +Simple invalid revset
> +
> +  $ hg test "(0"
> +  hg: parse error at 2: unexpected token: end
> +  ((0
> + ^ here)
> +  [255]
> diff -r 91701785c2c5 -r f850e5c85eee tests/test-completion.t
> --- a/tests/test-completion.t   Mon Feb 11 11:18:37 2019 -0500
> +++ b/tests/test-completion.t   Wed Feb 13 15:34:14 2019 +0100
> @@ -49,6 +49,7 @@
>summary
>tag
>tags
> +  test
>tip
>unbundle
>update
> @@ -340,6 +341,7 @@
>summary: remote
>tag: force, local, rev, remove, edit, message, date, user
>tags: template
> +  test:
>tip: patch, git, style, template
>unbundle: update
>update: clean, check, merge, date, rev, tool
> diff -r 91701785c2c5 -r f850e5c85eee tests/test-globalopts.t
> --- a/tests/test-globalopts.t   Mon Feb 11 11:18:37 2019 -0500
> +++ b/tests/test-globalopts.t   Wed Feb 13 15:34:14 2019 +0100
> @@ -380,6 +380,10 @@
> help  show help for a given topic or a help overview
> version   output version and copyright information
>
> +  Miscellaneous commands:
> +
> +   test  check if revset match anything
> +
>additional help topics:
>
>Mercurial identifiers:
> @@ -510,6 +514,10 @@
> help  show help for a given topic or a help overview
> version   output version and copyright information
>
> +  Miscellaneous commands:
> +
> +   test  check if revset match anything
> +
>additional help topics:
>
>Mercurial identifiers:
> diff -r 91701785c2c5 -r f850e5c85eee tests/test-help-hide.t
> --- a/tests/test-help-hide.tMon Feb 11 11:18:37 2019 -0500
> +++ b/tests/test-help-hide.tWed Feb 13 15:34:14 2019 +0100
> @@ -84,6 +84,10 @@
> help  show help for a given topic or a help overview
> version   output version and copyright information
>
> +  Miscellaneous commands:
> +
> +   test  check if revset match anything
> +
>additional help topics:
>
>Mercurial identifiers:
> @@ -218,6 +222,10 @@
> help  show help for a given topic or a help overview
> version   output version and copyright information
>
> +  Miscellaneous commands:
> +
> +   test  check if revset match anything
> +
>additional help topics:
>
>Mercurial identifiers:
> diff -r 91701785c2c5 -r f850e5c85eee tests/test-help.t
> --- a/tests/test-help.t Mon Feb 11 11:18:37 2019 -0500
> +++ b/tests/test-help.t Wed 

Re: caching pull - stable partitioning of bundle requests

[Boris FELD]

On 15/02/2019 21:16, Pulkit Goyal wrote:
>
>
> On Thu, Oct 4, 2018 at 6:16 PM Boris FELD  > wrote:
>
> The road for moving this in Core is clear, but not short. So far
> we have not been able to free the necessary time to do it. Between
> the paying-client work, we have to do to pay salaries (and keep
> users happy) and all the time we are already investing in the
> community, we are already fairly busy.
>
>
> In early 2017, Bitbucket gave $13, 500 to the Mercurial project to
> be spent to help evolution to move forward. As far as we know,
> this money is still unspent. Since stable range is a critical part
> of obsmarkers discovery, unlocking this money to be spent on
> upstreaming stable range would be a good idea (and fits its
> initial purposes). Paying for this kind of work will reduce the
> contention with client work and help us, or others, to dedicate
> time for it sooner than later.
>
>
> I definitely agree that obsmarker discovery is a critical part.
> Pulling from `hg-committed` is slower sometimes as compared to pulling
> on a repo (5-7x size of hg-committed) with server having thousands of
> heads.
>
> Do you have any updates on the stable-range cache? In the current
> state the cache is pretty big and a lot of people faced problem with
> the cache size.  Also in case of strip or some other commands, it
> rebuilts the cache which takes more than 10 minutes on large repo
> which is definitely a bummer. Are you working on making that better
> and take less size? How is experimentation of evolve+stablerange going on?

# Regarding the cache-size:

We know that the current version caches many entries that are trivial to
compute and does not need to be cached. In addition, the current storage
(SQLite) does not seem very efficient.

So the next iteration of the cache should be significantly smaller.


# Regarding cache invalidation:

A lot of the data in the caches are an inherent property of the
changeset and therefore immutable. It's easy to preserve then during
strip to avoid having to recompute things from scratch. In addition,
these immutable data should be exchange during pull alongside the
associated changesets to avoid client recomputing the same data over and
over.

The current implementation is an experimental/research implementation,
all this should get smoothed directly in Core during the upstreaming.


# Regarding  cache-computation speed:

The current implementation is a "research" version written in Python, it
is not geared toward efficiency and contains a lot of indirections that
were helpful to reach the current solution but are now getting in the
way of performance.

The initial implementation (in Evolve), focused on finding a solution
with good scaling property (good computational and space complexity).
However, we did not spend too much time improving the "constant" factor.
Now that we know where we are headed we can have a much better
implementation.

Once we have better on disk storage, native code and client/server
exchange of most of the data, the impact of stable-range should get to a
negligible level.


# Regarding what's next:

The experimental implementation cleared the unknown around stable-range
computation and caching. However, even if the road is clear, a sizable
amount of work remains, especially to move away from the unsuitable
SQLite storage. We think that putting the Bitbucket donation to use is
the best way to make sure this work gets done soon.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] test-sqlitestore: run sqlite3 with no init file

[Boris FELD]

Queued, thanks

On 19/02/2019 02:15, Jordi Gutiérrez Hermoso wrote:
> # HG changeset patch
> # User Jordi Gutiérrez Hermoso 
> # Date 1550533461 18000
> #  Mon Feb 18 18:44:21 2019 -0500
> # Node ID 3cac2f5ea9314a7d45079e629e0570bebcb3b6bf
> # Parent  37b33c34bf4f890857b5e8728febbc82a99368a5
> test-sqlitestore: run sqlite3 with no init file
>
> These tests were failing for me because I have a ~/.sqliterc that
> alters the default output. Tests should ignore any init file.
>
> diff --git a/tests/test-sqlitestore.t b/tests/test-sqlitestore.t
> --- a/tests/test-sqlitestore.t
> +++ b/tests/test-sqlitestore.t
> @@ -71,17 +71,17 @@ Can make a local commit
>  
>  That results in a row being inserted into various tables
>  
> -  $ sqlite3 .hg/store/db.sqlite << EOF
> +  $ sqlite3 .hg/store/db.sqlite -init /dev/null << EOF
>> SELECT * FROM filepath;
>> EOF
>1|foo
>  
> -  $ sqlite3 .hg/store/db.sqlite << EOF
> +  $ sqlite3 .hg/store/db.sqlite -init /dev/null << EOF
>> SELECT * FROM fileindex;
>> EOF
>
> 1|1|0|-1|-1|0|0|1||6/\xef(L\xe2\xca\x02\xae\xcc\x8d\xe6\xd5\xe8\xa1\xc3\xaf\x05V\xfe
>  (esc)
>  
> -  $ sqlite3 .hg/store/db.sqlite << EOF
> +  $ sqlite3 .hg/store/db.sqlite -init /dev/null << EOF
>> SELECT * FROM delta;
>> EOF
>1|1|   
> \xd2\xaf\x8d\xd2"\x01\xdd\x8dH\xe5\xdc\xfc\xae\xd2\x81\xff\x94"\xc7|0 (esc)
> @@ -93,7 +93,7 @@ Tracking multiple files works
>$ hg commit -A -m 'add bar'
>adding bar
>  
> -  $ sqlite3 .hg/store/db.sqlite << EOF
> +  $ sqlite3 .hg/store/db.sqlite -init /dev/null << EOF
>> SELECT * FROM filedata ORDER BY id ASC;
>> EOF
>
> 1|1|foo|0|6/\xef(L\xe2\xca\x02\xae\xcc\x8d\xe6\xd5\xe8\xa1\xc3\xaf\x05V\xfe|-1|-1|0|0|1|
>  (esc)
> @@ -104,7 +104,7 @@ Multiple revisions of a file works
>$ echo a >> foo
>$ hg commit -m 'modify foo'
>  
> -  $ sqlite3 .hg/store/db.sqlite << EOF
> +  $ sqlite3 .hg/store/db.sqlite -init /dev/null << EOF
>> SELECT * FROM filedata ORDER BY id ASC;
>> EOF
>
> 1|1|foo|0|6/\xef(L\xe2\xca\x02\xae\xcc\x8d\xe6\xd5\xe8\xa1\xc3\xaf\x05V\xfe|-1|-1|0|0|1|
>  (esc)
> ___
> 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

D5514: test: change test's diff generation to use mdiff for nicer output

[sangeet259 (Sangeet Kumar Mishra)]

sangeet259 added a comment.


  Hey @durin42 , take a look at the changes when you get time.

REPOSITORY
  rHG Mercurial

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

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