# Mar 25 2020

martinvonz updated the diff for D8324: py3: use integer division in histedit.

# Mar 20 2020

Since narrow is still experimental, I don't think we should try too hard for backward compatibility. We could introduce a new end-point for a new encoding and drop the old one in a couple of version.

+0, honestly. I won't require it, but I'd really rather we shaved this yak _now_ rather than when narrow has even more users.

I'm getting a bit frustrated with how much time I've spent on this, made worse by the fact that I agree with everything everyone's saying and so it's not like I'm frustrated at the review process, just how slow I've been at accomplishing this.
So, before I go down another rabbit hole, here's what I'm thinking:

• Server emits a new capability narrow-exp-1-escaped (in addition to the current narrow-exp-1, this is not replacing the existing capability)
martinvonz updated subscribers of D8190: nodemap: test that concurrent process don't see the pending transaction.

The parent patch (D8189) was a bit controversial. We don't need that patch if we apply the following patch on top of this one (making this test sleep-free):

# Mar 19 2020

This is pretty ugly and it doesn't seem that the next patch depends on it. You said you'll soon clean it up anyway, so I wonder if should just wait for the better solution instead. It doesn't seem like this fixes a serious bug so we have to rush it. Thoughts?

My initial motivation to rush the ugly way was "getting the behavior right to compare with the changeset centric one and being able to test performance improvement for the changeset centric one while having access to a specific repository". However, cancelling of all travel has cancelled the window to access that repo. I'll resubmit a cleaner versions soon.
since you did not commented on it, I assume the new behavior is fine by you, right?

martinvonz added a comment to D8289: resolve: add a --clear option for clearing the merge state.

I like the idea. IIRC, Ryan from FB hit similar issues in a sprint some years ago and came up with hg up --finish or something like that.
Maybe we should not let user clear the mergestate and suggest continue/<cmd-name> --continue if it's not result of update command. Thoughts?

Ho, that's a good idea. It looks like hg update --merge is the only command that do not have --continue support. So instead of adding a whole new flag and action to this exception, removing the exception seems like a better move. What do you think @martinvonz ?

fix: add a -s option to format a revision and its descendants
fix: move handling of --all into getrevstofix() for consistency

# Mar 18 2020

martinvonz updated the diff for D8288: fix: mark -r as advanced.

# Mar 17 2020

martinvonz updated the summary of D8289: resolve: add a --clear option for clearing the merge state.

# Mar 16 2020

fix: refactor getrevstofix() to define revisions first, then validate them
fix: disallow hg fix --all --working-dir
martinvonz updated the diff for D8288: fix: mark -r as advanced.
martinvonz added a comment to D8284: fix: disallow hg fix --all --working-dir.

If --working-dir and --all are redundant, I don't see anyharm in allowing both to be passed.

The idea was to inform users that they're doing something that's a little weird, in case they were hoping for it to do something else. I don't care much and I'm fine with dropping this patch if that's the consensus.

If the intend is to inform, maybe we could issue a warning?

martinvonz added a comment to D8284: fix: disallow hg fix --all --working-dir.

If --working-dir and --all are redundant, I don't see anyharm in allowing both to be passed.

# Mar 14 2020

tests: simplify test-fix-topology.t slightly by using a (case !)
tests: fix rebase test broken by earlier cleanup
rebase: accept multiple --base arguments (BC)
rebase: accept multiple --source arguments (BC)
rebase: mention -r argument in synopsis
rebase: remove unused defaults argument values from _definedestmap()

# Mar 13 2020

martinvonz added a comment to D8293: rebase: accept multiple --base arguments (BC).

I've updated the synopsis (also added another patch in the series for adding -r to the synopsis).

martinvonz updated the diff for D8292: rebase: accept multiple --source arguments (BC).
martinvonz updated the diff for D8293: rebase: accept multiple --base arguments (BC).
martinvonz retitled D8295: rebase: mention -r argument in synopsis from rebase: mention -r argument in synposis to rebase: mention -r argument in synopsis.
martinvonz retitled D8293: rebase: accept multiple --base arguments (BC) from rebase: accept multiple --base arguments to rebase: accept multiple --base arguments (BC).
D8136: phabricator: add a phabimport command is now accepted and ready to land.
martinvonz updated the diff for D8288: fix: mark -r as advanced.
martinvonz added inline comments to D8287: fix: add a -s option to format a revision and its descendants.
martinvonz updated the diff for D8288: fix: mark -r as advanced.
martinvonz updated the summary of D8282: tests: consistently put #testcases at beginning of file.
martinvonz added a comment to D8282: tests: consistently put #testcases at beginning of file.

Can you drop your change to tests/test-push-race.t from this patch ?

martinvonz added a comment to D8282: tests: consistently put #testcases at beginning of file.

That's a good point, doing it for #require too would be more consistent.
I would make a difference between test that do not make too much of an effort to have a title + early documentation and the one who actually make effort to have a formal format for their title and documentation (the one with =====\ntitle\n===== or title\n=====).
I would be fine with having the requires/testcases right after the title when it make senses. I think there are some instance where the variants are formally documented, and the #testcase block is part of that. It might make sense to keep them at that location.

martinvonz added a comment to D8282: tests: consistently put #testcases at beginning of file.

(like imports and includes in other languages)

Precisely, import and includes usually comes after the initial module licence, title and documentation. So I would like the testcase declaration to comes after the initial module title (and maybe doc).

The Windows path changes seem like a good idea.
Would quoting paths with commas eliminate the need for custom escaping? I don't feel strongly about it, but custom escaping always feels weird to me. (I fact, a coworker did some homebrew escaping for CSV files a few days ago, but I forget how it ultimately ended up.)

Let me play with that a bit, I think it'll work and be detectable on the server since the first character can't currently be a double-quote, so there wouldn't really be any BC issues aside from the pconvert (which wouldn't be as important anymore, but still probably a good idea?)

I haven't played with narrow yet, so I'm not sure of the context. Are these user input paths that would end up being ignored/rejected if a Windows user used path\to\file when talking to a Unix server? Or are these stored in a tracked file? (Which I think could still cause problems.) I can't think of a good reason to stay inconsistent, and it is still experimental, so it still seems like a good idea while we still can fix it.

martinvonz added a comment to D8282: tests: consistently put #testcases at beginning of file.

I very much agree with Matt

martinvonz added inline comments to D8282: tests: consistently put #testcases at beginning of file.

The Windows path changes seem like a good idea.
Would quoting paths with commas eliminate the need for custom escaping? I don't feel strongly about it, but custom escaping always feels weird to me. (I fact, a coworker did some homebrew escaping for CSV files a few days ago, but I forget how it ultimately ended up.)

Let me play with that a bit, I think it'll work and be detectable on the server since the first character can't currently be a double-quote, so there wouldn't really be any BC issues aside from the pconvert (which wouldn't be as important anymore, but still probably a good idea?)

# Mar 12 2020

martinvonz added a comment to D8244: copies: fix the changeset based algorithm regarding merge.

In 99ebde4fec99, we changed the list of files stored into the files field.
This lead to the changeset centric copy algorithm to break in various merge
situation involving merge.

Could you explain why it broke? It's hard to review this patch without really knowing what the problem or the solution is.

Outdated information from p1 could overwrite newer information from p2.

The new implementation focus on correctness. Performance improvement will come
later.

How much slower is it? Could you run some of those benchmarks you have run on previous patches touching this code? How do you plan to improve it?

There are two new calls that might degrade performance. This isancestor call that is easy to cache in memory. And the "ismerged" logic that is easy to cache on disk with the rest of the copy related information (the case is rare).
There is some win to have in python, but the main win will be the move the Rust algorithm (that need to be updated with the new logic). Moving to rust give a very large performance boost on the slow cases (usually over 10x, sometime 100x IIRC). That is the one I care about.

This is pretty ugly and it doesn't seem that the next patch depends on it. You said you'll soon clean it up anyway, so I wonder if should just wait for the better solution instead. It doesn't seem like this fixes a serious bug so we have to rush it. Thoughts?

# Mar 11 2020

FYI, I'd like to look at this patch, but I'm busy with other things right now (switching back and forth between browser tabs to delay the interview feedback that I'm actually supposed to write), so it will take a bit longer before I'll find time for this one.

# Mar 10 2020

martinvonz added inline comments to D8265: git: key off git in .hg/requires rather than separate file.
martinvonz added inline comments to D8265: git: key off git in .hg/requires rather than separate file.
martinvonz added inline comments to D8265: git: key off git in .hg/requires rather than separate file.

@martinvonz this (and next few patches) seems accepted by you and Augie. Should I go ahead and push it or I missed some discussion on IRC about it?

You can push it. I wanted to finish the cleanup to the regex grouping that I mentioned earlier, but that can be done separately. But that's the only reason I haven't queued this patch anyway.

You mean cleanup on the Python side or on the rust side? IIUC, the rust side is fine now.

@martinvonz this (and next few patches) seems accepted by you and Augie. Should I go ahead and push it or I missed some discussion on IRC about it?

As explained in this comment https://phab.mercurial-scm.org/D8030#120771 I find the idea of usign a changeset in place of the working copy interresting. However, this is a larger big UX change that seems to deserve a wider discussion with more of the community involved. In particular I am not convinced about the --rev flag usage.
See the linked comment for more details.
(Sorry for the delay this will involves, I wish the idea had explicitly surfaced earlier).

# Mar 9 2020

git: don't fail import when pygit2 is not install
hghave: add a check for pygit2
martinvonz added inline comments to D8268: git: don't fail import when pygit2 is not install.
martinvonz updated the diff for D8268: git: don't fail import when pygit2 is not install.
git: make {shortest()} return shortest *unique* prefix
merge with stable

I know this has already been queue and I'm just slow, but could you send follow-up patches to address my comments?

martinvonz added a comment to D8254: nodemap: fix missing r-prefix on regular expression.

Good catch, look good to me. Can we drop the skip-blame just adding a missing r-prefix inflight?

563dfdfd01a4 is public, so no?

I am confused, because this diff was not even landed. when you commented this.

Anyway, I think I misunderstood your original comment because I didn't see the quotes in it, so I thought you were asking reviewers to add the missing r'' prefix in flight.

Haa, I understand the misunderstanding now. Now that things are clearer, Can we fix the queued changeset ?

martinvonz added a comment to D8254: nodemap: fix missing r-prefix on regular expression.

Good catch, look good to me. Can we drop the skip-blame just adding a missing r-prefix inflight?

563dfdfd01a4 is public, so no?

I am confused, because this diff was not even landed. when you commented this.

git: make {shortest()} return shortest *unique* prefix