{"state":{"revisions":[{"id":"9866","callsign":"HG","title":"debugshell: add a simple command for starting an interactive shell","author":"joerg.sonnenberger","summary":"This simplifies interactive exploration of the Mercurial APIs.\nThe ui and repo instances are provided as local variables.","testPlan":"","lineCount":"9","dependsOn":[],"reviewers":[],"ccs":["mharbison72","mercurial-patches"],"actions":[{"type":"inline","comment":"Should `repo` be optional?  It's somewhat less useful that way, but it's valid to run some commands with no repo, so it might be worth the ability to poke around at the internals in that state.","replyTo":null,"isNewFile":"1","line":"3721","lineLength":"0","path":"mercurial\/debugcommands.py","diffId":"25248","author":"mharbison72","id":"149452","dateCreated":"1611618617","dateModified":"1611618617"},{"type":"comment","comment":"Ultimately I'd like to add support for a `-m` to be able to `pip install --user`.  I assume there's a way to do that with the `code` module?\n\nAs mentioned in IRC, `-c ...` can be done with echoing into this command.  I'll have to look at some of my setup script stuff, but I think it might be nice to have `-c` that doesn't print all of the REPL banner stuff because keyring on Linux usually requires running some python commands to print where various files are stored.  But that's all future stuff.  I'm happy with this once the optional repo question is answered\/fixed.  (Also, this needs `hg fix`.)","author":"mharbison72","id":"149451","dateCreated":"1611618617","dateModified":"1611618617"},{"type":"update","diffId":"25248","author":"joerg.sonnenberger","id":"149445","dateCreated":"1611616788","dateModified":"1611616788"}],"dateCreated":"1611616788","dateModified":"1611618617","status":"Needs Review"},{"id":"9865","callsign":"HG","title":"store: use `endswith` to detect revlog extension","author":"marmoute","summary":"Suggested by Gregory Szorc.","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25247","author":"marmoute","id":"149439","dateCreated":"1611610325","dateModified":"1611610325"}],"dateCreated":"1611610325","dateModified":"1611612129","status":"Needs Review"},{"id":"9864","callsign":"HG","title":"rust: Remove hex parsing from the nodemap","author":"SimonSapin","summary":"Separating concerns simplifies error types.","testPlan":"","lineCount":"90","dependsOn":["9863"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25246","author":"SimonSapin","id":"149431","dateCreated":"1611609223","dateModified":"1611609223"}],"dateCreated":"1611609223","dateModified":"1611611200","status":"Needs Review"},{"id":"9863","callsign":"HG","title":"rust: Make NodePrefix allocation-free and Copy, remove NodePrefixRef","author":"SimonSapin","summary":"The `*Ref` struct only existed to avoid allocating `Vec`s\nwhen cloning `NodePrefix`, but we can avoid having `Vec`\nin the first place by using an inline array instead.\n\nThis makes `NodePrefix` 21 bytes (with 1\u00a0for the length)\nwhich is smaller than before as `Vec` alone is 24 bytes.","testPlan":"","lineCount":"331","dependsOn":["9862"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25245","author":"SimonSapin","id":"149423","dateCreated":"1611609202","dateModified":"1611609202"}],"dateCreated":"1611609202","dateModified":"1611611197","status":"Needs Review"},{"id":"9862","callsign":"HG","title":"rust: Exclude empty node prefixes","author":"SimonSapin","summary":"We presumably don\u2019t want `--rev \"\"` to select every single revision,\neven though the empty string is a prefix of all strings.","testPlan":"","lineCount":"6","dependsOn":["9861"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25244","author":"SimonSapin","id":"149415","dateCreated":"1611609176","dateModified":"1611609176"}],"dateCreated":"1611609176","dateModified":"1611611195","status":"Needs Review"},{"id":"9861","callsign":"HG","title":"rust: Simplify error type for reading hex node IDs","author":"SimonSapin","summary":"If a string is not valid hexadecimal it\u2019s not that useful to track the precise reason.","testPlan":"","lineCount":"110","dependsOn":["9860"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25243","author":"SimonSapin","id":"149407","dateCreated":"1611609160","dateModified":"1611609160"}],"dateCreated":"1611609160","dateModified":"1611611193","status":"Needs Review"},{"id":"9860","callsign":"HG","title":"rust: replace Node::encode_hex with std::fmt::LowerHex","author":"SimonSapin","summary":"This avoids allocating intermediate strings.","testPlan":"","lineCount":"28","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25242","author":"SimonSapin","id":"149401","dateCreated":"1611609143","dateModified":"1611609143"}],"dateCreated":"1611609143","dateModified":"1611611191","status":"Needs Review"},{"id":"9020","callsign":"HG","title":"sshpeer: avoid having a destructor that can block forks forever","author":"valentin.gatienbaron","summary":"This is solution 2. that was described in the previous commit.","testPlan":"","lineCount":"27","dependsOn":["9019"],"reviewers":[],"ccs":["marmoute","durin42","indygreg","mercurial-patches"],"actions":[{"type":"comment","comment":"Closing the peer is what I was describing as solution 3 in D9019. But I think I was wrong in saying that it doesn't help with calls to logtoprocess in the middle of commands. I also just noticed that `pull` does that, in fact. I'll try and find some time to do that.","author":"valentin.gatienbaron","id":"149399","dateCreated":"1611593375","dateModified":"1611593442"},{"type":"comment","comment":"Having thing explicitly close is probably better, why maybe a developer warning when this isn't the case ?","author":"marmoute","id":"146214","dateCreated":"1610061180","dateModified":"1610061180"},{"type":"comment","comment":"I meant for this change to be in addition to D9019, rather than an alternative, for robustness as written in a bit more detail in the commit message of D9019.\n\nAlthough looking at these couple of changes again, maybe instead I could close the peers explicitly in push\/pull\/incoming\/outgoing\/id. Such a change doesn't fix all deadlocks on its own, but along with D9019, it should be enough.","author":"valentin.gatienbaron","id":"138410","dateCreated":"1602735217","dateModified":"1602735217"},{"type":"comment","comment":"So I think I actually prefer D9019 by a hair here. @indygreg do you have a preference?","author":"durin42","id":"138351","dateCreated":"1602694183","dateModified":"1602694183"},{"type":"update","diffId":"22641","author":"valentin.gatienbaron","id":"135158","dateCreated":"1600096039","dateModified":"1600096039"}],"dateCreated":"1600096039","dateModified":"1611593442","status":"Needs Review"},{"id":"9019","callsign":"HG","title":"procutil: avoid using os.fork() to implement runbgcommand","author":"valentin.gatienbaron","summary":"NB: this only works with py3. I'm hoping that maybe it won't be\nnecessary to support py2 in a couple of months?\n\nWe ran into the following deadlock:\n\n- some command creates an ssh peer, then raises without explicitly\n  closing the peer (hg id + extension in our case)\n\n- dispatch catches the exception, calls ui.log('commandfinish', ..)\n  (the sshpeer is still not closed), which calls logtoprocess, which\n  calls procutil.runbgcommand.\n\n- in the child of runbgcommand's fork(), between the fork and the\n  exec, the opening of file descriptors triggers a gc which runs the\n  destructor for sshpeer, which waits on ssh's stderr being closed,\n  which never happens since ssh's stderr is held open by the parent of\n  the fork where said destructor hasn't run\n\nI don't know if there's more subtlety to it, because even though the\nproblem is determistic, it is very fragile, so I didn't manage to\nreduce it.\n\nI can imagine three ways of tackling this problem:\n1. don't run any python between fork and exec in runbgcommand\n2. make the finalizer harmless after the fork\n3. close the peer without relying on gc behavior\n\n3 wouldn't help with calls to logtoprocess in the middle of commands.\nSo this commit implements 1, and the next commit will do 2 for\nrobustness (it might help with the forks from worker.py in hg pull\n-u).\n\nPerformance wise: at low memory usage, it's an improvement. At higher\nmemory usage, it's about 2x faster than before when ensurestart=True,\nbut 2x slower when ensurestart=False. Not sure if that matters. The\nreason for that last bit is that the subprocess.Popen always waits for\nthe execve to finish, and at high memory usage, execve is slow because\nit deallocates the large page table. Numbers and script:\n\n\t\t\t\t before after\n    mem=1.0GB, ensurestart=True  52.1ms 26.0ms\n    mem=1.0GB, ensurestart=False 14.7ms 26.0ms\n    mem=0.5GB, ensurestart=True  23.2ms 11.2ms\n    mem=0.5GB, ensurestart=False  6.2ms 11.3ms\n    mem=0.2GB, ensurestart=True  15.7ms 7.4ms\n    mem=0.2GB, ensurestart=False  4.3ms 8.1ms\n    mem=0.0GB, ensurestart=True   2.3ms 0.7ms\n    mem=0.0GB, ensurestart=False  0.8ms 0.8ms\n\n    import time\n    for memsize in [1_000_000_000, 500_000_000, 250_000_000, 0]:\n        mem = 'a' * memsize\n        for ensurestart in [True, False]:\n            now = time.time()\n            n = 100\n            for i in range(n):\n                procutil.runbgcommand([b'true'], {}, ensurestart=ensurestart)\n            after = time.time()\n            ms = (after - now) \/ float(n) * 1000\n            print(f'mem={memsize \/ 1e9:.1f}GB, ensurestart={ensurestart} -> {ms:.1f}ms')","testPlan":"","lineCount":"102","dependsOn":[],"reviewers":[],"ccs":["marmoute","pulkit","durin42","indygreg","mercurial-patches"],"actions":[{"type":"comment","comment":"What's holding this back is lack of py2 compatibility. Although maybe I want to wait it out at this point. Do we expect to drop py2 in a few days, after 5.7 is released for instance?","author":"valentin.gatienbaron","id":"149398","dateCreated":"1611592708","dateModified":"1611592866"},{"type":"comment","comment":"Gentle ping on this. I read the discussion and it does not seems clear to me what is holding it back.","author":"marmoute","id":"146212","dateCreated":"1610059827","dateModified":"1610059827"},{"type":"comment","comment":"I rebased, but there's nothing new here (apart from conflict resolution).\nThe discussion for py2 support was not super conclusive. But even given that D7258 uses py3 by default except on windows, and the fact the code changed here doesn't run on windows, I think I still need to make this change work with py2, so py2 issues from windows users can still be investigated from linux.","author":"valentin.gatienbaron","id":"139636","dateCreated":"1604883228","dateModified":"1604883228"},{"type":"update","diffId":"23438","author":"valentin.gatienbaron","id":"139626","dateCreated":"1604881820","dateModified":"1604881820"},{"type":"comment","comment":"Ok. When I sent this, I thought the py3 switch was further along than it seems to be. I should be able to make this work on py2 (although I think it would merely reduce the chance of deadlock on py2).\n\nThe slowdown is a bit annoying, and while it doesn't have to happen in principle, I looked in the implementation of `subprocess` and what I remember is that there was no way to make python not wait for the child to finish its `execve`.","author":"valentin.gatienbaron","id":"138411","dateCreated":"1602736420","dateModified":"1602736556"},{"type":"comment","comment":"I don't love the performance loss when `ensurestart=False` (that'll show up in some performance metrics at Google, but 10ms is livable for the correctness win).\n\nIs there some way we could make this work on both Python 2 and 3 and just let it be suboptimally slow on Python 2? I don't think we're (despite my desires) ready to cut Python 2 loose. :(","author":"durin42","id":"138348","dateCreated":"1602693685","dateModified":"1602693685"},{"type":"comment","comment":"This mostly goes over my head. @durin42 @indygreg seems like something which needs your eyes.","author":"pulkit","id":"136899","dateCreated":"1601470480","dateModified":"1601470480"},{"type":"update","diffId":"22640","author":"valentin.gatienbaron","id":"135152","dateCreated":"1600096035","dateModified":"1600096035"}],"dateCreated":"1600096035","dateModified":"1611592708","status":"Needs Review"},{"id":"9859","callsign":"HG","title":"rust: replace an unsafe use of transmute with a safe use of bytes-cast","author":"SimonSapin","summary":"","testPlan":"","lineCount":"15","dependsOn":["9788"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25241","author":"SimonSapin","id":"149386","dateCreated":"1611570888","dateModified":"1611570888"}],"dateCreated":"1611570888","dateModified":"1611570888","status":"Needs Review"},{"id":"9788","callsign":"HG","title":"rust: use the bytes-cast crate to parse persistent nodemaps","author":"SimonSapin","summary":"This crate casts pointers to custom structs, with compile-time safety checks,\nfor easy and efficient binary data parsing.\n\nSee https:\/\/crates.io\/crates\/bytes-cast and\nhttps:\/\/docs.rs\/bytes-cast\/0.1.0\/bytes_cast\/","testPlan":"","lineCount":"167","dependsOn":[],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"149223","dateCreated":"1611322549","dateModified":"1611322549"},{"type":"update","diffId":"25109","author":"SimonSapin","id":"148596","dateCreated":"1610979726","dateModified":"1610979726"},{"type":"inline","comment":"I'd use `expect` to explain better why this cannot happen.","replyTo":null,"isNewFile":"1","line":"614","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"24900","author":"Alphare","id":"147819","dateCreated":"1610725427","dateModified":"1610725427"},{"type":"inline","comment":"If you're not going to use a constant (as per my comment above), use `size_of` as `mem` is already imported.","replyTo":null,"isNewFile":"1","line":"388","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"24900","author":"Alphare","id":"147818","dateCreated":"1610725426","dateModified":"1610725426"},{"type":"inline","comment":"Could that be kept as the following and reused later?\n```rust\npub const BLOCK_SIZE: usize = size_of::<Block>;\n```","replyTo":null,"isNewFile":"0","line":"225","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"24900","author":"Alphare","id":"147817","dateCreated":"1610725426","dateModified":"1610725426"},{"type":"inline","comment":"This comment is now obsolete.","replyTo":null,"isNewFile":"1","line":"225","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"24900","author":"Alphare","id":"147816","dateCreated":"1610725426","dateModified":"1610725426"},{"type":"update","diffId":"24900","author":"SimonSapin","id":"147810","dateCreated":"1610723532","dateModified":"1610723532"}],"dateCreated":"1610723532","dateModified":"1611570888","status":"Needs Review"},{"id":"9775","callsign":"HG","title":"upgrade: update only requirements if we can","author":"pulkit","summary":"Upgrade operations which involves just upgrading requirements earlier used to go\nthrough whole revlog cloning business.\nNow we just upgrade the requirement and skip the cloning part.","testPlan":"","lineCount":"46","dependsOn":["9774"],"reviewers":["mharbison72"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"149111","dateCreated":"1611239334","dateModified":"1611239334"},{"type":"update","diffId":"25203","author":"baymax","id":"149110","dateCreated":"1611239334","dateModified":"1611239334"},{"type":"accept","author":"mharbison72","id":"148829","dateCreated":"1611023028","dateModified":"1611023028"},{"type":"update","diffId":"24855","author":"pulkit","id":"147592","dateCreated":"1610628887","dateModified":"1610628887"}],"dateCreated":"1610628887","dateModified":"1611564804","status":"Accepted"},{"id":"9774","callsign":"HG","title":"engine: add `if True` to prepare for next patch","author":"pulkit","summary":"This will help making next patch easier to read.","testPlan":"","lineCount":"143","dependsOn":["9773"],"reviewers":["mharbison72"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"149109","dateCreated":"1611239333","dateModified":"1611239333"},{"type":"update","diffId":"25202","author":"baymax","id":"149108","dateCreated":"1611239333","dateModified":"1611239333"},{"type":"accept","author":"mharbison72","id":"148827","dateCreated":"1611022944","dateModified":"1611022944"},{"type":"update","diffId":"24854","author":"pulkit","id":"147584","dateCreated":"1610628881","dateModified":"1610628881"}],"dateCreated":"1610628881","dateModified":"1611564801","status":"Accepted"},{"id":"9773","callsign":"HG","title":"test: unquiet few tests to demonstrate changes in upcoming patches","author":"pulkit","summary":"Upcoming patches will skip revlog cloning for share-safe upgrades.","testPlan":"","lineCount":"56","dependsOn":["9772"],"reviewers":["mharbison72"],"ccs":["mharbison72","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"149107","dateCreated":"1611239331","dateModified":"1611239331"},{"type":"update","diffId":"25201","author":"baymax","id":"149105","dateCreated":"1611239331","dateModified":"1611239331"},{"type":"inline","comment":"This probably needs to be updated now that the share-safe stuff isn't experimental.","replyTo":null,"isNewFile":"1","line":"576","lineLength":"1","path":"tests\/test-share-safe.t","diffId":"24853","author":"mharbison72","id":"148825","dateCreated":"1611022915","dateModified":"1611022915"},{"type":"reject","author":"mharbison72","id":"148824","dateCreated":"1611022915","dateModified":"1611022915"},{"type":"update","diffId":"24853","author":"pulkit","id":"147576","dateCreated":"1610628876","dateModified":"1610628876"}],"dateCreated":"1610628876","dateModified":"1611564799","status":"Needs Review"},{"id":"9772","callsign":"HG","title":"upgrade: mark sharesafe improvement as only touching requirements","author":"pulkit","summary":"Upgrading the repository to use share safe functionality only touches\nrequirements.","testPlan":"","lineCount":"6","dependsOn":["9771"],"reviewers":["mharbison72"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"149104","dateCreated":"1611239330","dateModified":"1611239330"},{"type":"update","diffId":"25200","author":"baymax","id":"149103","dateCreated":"1611239330","dateModified":"1611239330"},{"type":"accept","author":"mharbison72","id":"148821","dateCreated":"1611022785","dateModified":"1611022785"},{"type":"update","diffId":"24852","author":"pulkit","id":"147568","dateCreated":"1610628872","dateModified":"1610628872"}],"dateCreated":"1610628872","dateModified":"1611564796","status":"Accepted"},{"id":"9771","callsign":"HG","title":"actions: calculate what all parts does the operation touches","author":"pulkit","summary":"To make upgrade work less in certain situations, we need to teach it to find out\nwhat all parts of repository current operation is touching.\n\nThis patch starts doing that. In next patch we will be setting values in\nimprovement objects. For now, we assume everything touches everything.","testPlan":"","lineCount":"90","dependsOn":["9770"],"reviewers":["mharbison72"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"149102","dateCreated":"1611239329","dateModified":"1611239329"},{"type":"update","diffId":"25199","author":"baymax","id":"149101","dateCreated":"1611239329","dateModified":"1611239329"},{"type":"accept","author":"mharbison72","id":"148819","dateCreated":"1611022747","dateModified":"1611022747"},{"type":"update","diffId":"24851","author":"pulkit","id":"147560","dateCreated":"1610628867","dateModified":"1610628867"}],"dateCreated":"1610628867","dateModified":"1611564793","status":"Accepted"},{"id":"9770","callsign":"HG","title":"upgrade: don't create store backup if `--no-backup` is passed","author":"pulkit","summary":"If the user explicitly mentioned that they don't need backup, then let's not\ncreate it.","testPlan":"","lineCount":"59","dependsOn":["9677"],"reviewers":["mharbison72"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"149100","dateCreated":"1611239327","dateModified":"1611239327"},{"type":"update","diffId":"25198","author":"baymax","id":"149099","dateCreated":"1611239327","dateModified":"1611239327"},{"type":"accept","author":"mharbison72","id":"148817","dateCreated":"1611022559","dateModified":"1611022559"},{"type":"update","diffId":"24850","author":"pulkit","id":"147552","dateCreated":"1610628862","dateModified":"1610628862"}],"dateCreated":"1610628862","dateModified":"1611564790","status":"Accepted"},{"id":"9843","callsign":"HG","title":"revlog: introduce v2 format","author":"Alphare","summary":"As documented in [1], this is still tentative and could be subject to change,\nbut we need to lay down the foundations in order to work on the next abstraction\nlayers.\n\n\n[1] https:\/\/www.mercurial-scm.org\/wiki\/RevlogV2Plan","testPlan":"","lineCount":"166","dependsOn":[],"reviewers":["indygreg"],"ccs":["pulkit","marmoute","mharbison72","mercurial-patches"],"actions":[{"type":"comment","comment":"I'm not going to review this right now, but I have prior art at https:\/\/www.mercurial-scm.org\/pipermail\/mercurial-devel\/2017-February\/093657.html and https:\/\/www.mercurial-scm.org\/pipermail\/mercurial-devel\/2017-May\/097960.html that might be worth a read. I believe the wiki page on this format only contains a subset of the deficiencies I outlined in the 1st link.","author":"indygreg","id":"149373","dateCreated":"1611539443","dateModified":"1611539443"},{"type":"inline","comment":"IIUC, this change can also be a separate patch.","replyTo":null,"isNewFile":"1","line":"44","lineLength":"0","path":"mercurial\/pure\/parsers.py","diffId":"25185","author":"pulkit","id":"149246","dateCreated":"1611333627","dateModified":"1611333627"},{"type":"inline","comment":"This can be a separate patch and will be easy one to push.","replyTo":null,"isNewFile":"1","line":"3639","lineLength":"0","path":"mercurial\/localrepo.py","diffId":"25185","author":"pulkit","id":"149245","dateCreated":"1611333627","dateModified":"1611333627"},{"type":"comment","comment":"Couple of changes from this patch can be separated and send individually as `prepare for revlog v2` which will help speed up review.","author":"pulkit","id":"149244","dateCreated":"1611333627","dateModified":"1611333627"},{"type":"comment","comment":">>! In D9843#149037, @marmoute wrote:\n>>>! In D9843#149035, @mharbison72 wrote:\n>> Can we get space for extra flags for things not supported by the filesystem?  I'm thinking specifically `+x` and symlink support on Windows.\n>> \n>> https:\/\/www.mercurial-scm.org\/wiki\/DirState#Proposed_extensions\n> \n> That would be a dirstate thing, not a revlog thing, right ?\n\nOops, yeah. It\u2019s been one of those days...\n","author":"mharbison72","id":"149038","dateCreated":"1611185764","dateModified":"1611185764"},{"type":"comment","comment":">>! In D9843#149035, @mharbison72 wrote:\n> Can we get space for extra flags for things not supported by the filesystem?  I'm thinking specifically `+x` and symlink support on Windows.\n> \n> https:\/\/www.mercurial-scm.org\/wiki\/DirState#Proposed_extensions\n\nThat would be a dirstate thing, not a revlog thing, right ?","author":"marmoute","id":"149037","dateCreated":"1611183875","dateModified":"1611183875"},{"type":"comment","comment":"Can we get space for extra flags for things not supported by the filesystem?  I'm thinking specifically `+x` and symlink support on Windows.\n\nhttps:\/\/www.mercurial-scm.org\/wiki\/DirState#Proposed_extensions","author":"mharbison72","id":"149035","dateCreated":"1611182387","dateModified":"1611182387"},{"type":"update","diffId":"25185","author":"Alphare","id":"149004","dateCreated":"1611175530","dateModified":"1611175530"}],"dateCreated":"1611175530","dateModified":"1611539443","status":"Needs Review"},{"id":"9856","callsign":"HG","title":"packaging: allow specifying modules to include with py2exe","author":"mharbison72","summary":"Maybe this was missing because there wasn't a need for it.","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":"This is meant for stable, to avoid a partial installation.","author":"mharbison72","id":"149372","dateCreated":"1611538470","dateModified":"1611538470"},{"type":"update","diffId":"25237","author":"mharbison72","id":"149359","dateCreated":"1611538420","dateModified":"1611538420"}],"dateCreated":"1611538420","dateModified":"1611538470","status":"Needs Review"},{"id":"9857","callsign":"HG","title":"packaging: include `windows_curses` when building py2exe","author":"mharbison72","summary":"The `_curses.pyd` module was previously being included by py2exe's module\nsearch, but it left out `_curses_panel.pyd`.","testPlan":"","lineCount":"11","dependsOn":["9856"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25238","author":"mharbison72","id":"149365","dateCreated":"1611538422","dateModified":"1611538422"}],"dateCreated":"1611538422","dateModified":"1611538423","status":"Needs Review"},{"id":"9848","callsign":"HG","title":"fastexport: committer name should not be quoted","author":"roy","summary":"","testPlan":"","lineCount":"34","dependsOn":[],"reviewers":[],"ccs":["durin42","Alphare","joerg.sonnenberger","mercurial-patches"],"actions":[{"type":"comment","comment":"So if I send an email, using thunderbird, 9 folders or gmail and look at the email source the email name is not quoted.\nAll I ask is that hg behaves the same way. That should not be took much to ask?","author":"roy","id":"149357","dateCreated":"1611530196","dateModified":"1611530196"},{"type":"comment","comment":">>! In D9848#149355, @joerg.sonnenberger wrote:\n> Horrible parsing code, but not relevant for here. I gave the reasons why the original code used \"\", but I don't care either way if git doesn't fall apart anymore than already does when an address is not pretending to be a mail.\n\nYou gave your reasons, but I still cannot find any reference to git fast-import spec respecting any RFC formatting as per email address quoting.\nI quoted the spec where it says it takes it free-form, which describes what the code does.\n\n>>! In D9848#149232, @joerg.sonnenberger wrote:\n> The output is entirely valid according to the git format specification.\n\nYes, the output is valid in that it's free form, but you have forced quoted where none should be.\nYou might as well put more garbage in there and it's still valid, but it's not correct.","author":"roy","id":"149356","dateCreated":"1611530051","dateModified":"1611530051"},{"type":"comment","comment":"Horrible parsing code, but not relevant for here. I gave the reasons why the original code used \"\", but I don't care either way if git doesn't fall apart anymore than already does when an address is not pretending to be a mail.","author":"joerg.sonnenberger","id":"149355","dateCreated":"1611529365","dateModified":"1611529365"},{"type":"comment","comment":"Finds the author command\nhttps:\/\/github.com\/git\/git\/blob\/7f7ebe054af6d831b999d6c2241b9227c4e4e08d\/builtin\/fast-import.c#L2689\n\nWhich sends the text after the command to parse_ident() here.\nhttps:\/\/github.com\/git\/git\/blob\/7f7ebe054af6d831b999d6c2241b9227c4e4e08d\/builtin\/fast-import.c#L1938\n\nFirst, it verifies there is an email address in angled brackets.\nThen it creates a string buffer based structure where it places the exact text from the start upto and including closing angled bracket of the email address.\nIt then verifies the date and appends it's interpretation of that as well.\n\nNow we go back to continue in the first function to actual use this data in the commit:\nhttps:\/\/github.com\/git\/git\/blob\/7f7ebe054af6d831b999d6c2241b9227c4e4e08d\/builtin\/fast-import.c#L2764\n\nSo basically it just stores what it's given from the parse_ident function.\nThere is no attempt to parse the users name to remove any quotation added.\n\nAs to the specification - where do you see the need to quote?\nAll I can find is this\n```Here <name> is the person\u2019s display name (for example \u201cCom M Itter\u201d) and <email> is the person\u2019s email address (\u201ccm@example.com\u201d). LT and GT are the literal less-than (\\x3c) and greater-than (\\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that <name> and <email> are free-form and may contain any sequence of bytes, except LT, GT and LF. <name> is typically UTF-8 encoded.```\nThe quotes here show the value, not that it's quoted - after all, email address uses <>, not \"\".","author":"roy","id":"149296","dateCreated":"1611348322","dateModified":"1611348400"},{"type":"comment","comment":"The basic concern I have here is that I have stepped on git's toes here before and the field is nowhere near as free text as it is supposed to be according to the specification. So any change should at least double check what the git code is actually doing, because it doesn't do the same as the documentation from what I have seen. Case in point is the data handling, where git does distingiush between +0 and -0.","author":"joerg.sonnenberger","id":"149263","dateCreated":"1611346830","dateModified":"1611346830"},{"type":"comment","comment":"Should we add a test that, if git-fast-import is available, actually tries the import and verifies that things look reasonable?","author":"durin42","id":"149262","dateCreated":"1611345352","dateModified":"1611345352"},{"type":"comment","comment":"So just for kicks I did hg fastexport on my dhcpcd repo where the author names look fine.\nI then did hg fastimport (3rd party plugin) on the resultant fast-import file generated from the above.\n\nAnd hg also displayed \"Roy Marples\" <roy@marples.name> which again looks wrong.","author":"roy","id":"149236","dateCreated":"1611328019","dateModified":"1611328019"},{"type":"comment","comment":"Using git to create a fast-import, the comitter is never quoted.\nAgain, using git to import a quoted comitter name, preserves the quotes.\nUsing git log to display the import, the comitters name appears as \"Roy Marples\" <roy@marples.name> which just looks wrong.\n\nOther systems that creat a fast-import file such as Fossil don't quote either.\n\nWhile you might not see any reason to change this as per the specification which I can't argue with, no existing tooling other than hg fastexport actually quotes or understands quotes.\n\nSo @joerg.sonnenberger  I respectfully ask why we need to quote here? I see no reason to.","author":"roy","id":"149235","dateCreated":"1611327043","dateModified":"1611327043"},{"type":"comment","comment":"The output is entirely valid according to the git format specification. It is also entirely valid under the formatting rules for email addresses, which was supposed to be the origin of this identifiers. As such, I see no reason to change anything.","author":"joerg.sonnenberger","id":"149232","dateCreated":"1611325562","dateModified":"1611325562"},{"type":"comment","comment":"@joerg.sonnenberger is there any way that this is not right?","author":"Alphare","id":"149219","dateCreated":"1611321520","dateModified":"1611321520"},{"type":"update","diffId":"25208","author":"roy","id":"149133","dateCreated":"1611282531","dateModified":"1611282531"}],"dateCreated":"1611282531","dateModified":"1611530196","status":"Needs Review"},{"id":"9684","callsign":"HG","title":"copies-rust: move CPU-heavy Rust processing into a child thread","author":"SimonSapin","summary":"\u2026 that runs in parallel with the parent thread fetching data.\nThis can be disabled through a new config. CLI example:\n\n    hg --config=devel.copy-tracing.multi-thread=no\n\nFor now both threads use the GIL, later commits will reduce this.","testPlan":"","lineCount":"109","dependsOn":["9683"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"149340","dateCreated":"1611465803","dateModified":"1611465803"},{"type":"inline","comment":"I feel that starting a pool of multiple thread to run a single task on it and leaving it running until process exit is counter-productive compared to the one thread started and then stopped here. Unless `combine_changeset_copies_wrapper` itself is called with high concurrency from many Python threads (which would contend the GIL) we\u2019re not gonna have many of these Rust threads.","replyTo":"149197","isNewFile":"1","line":"78","lineLength":"0","path":"rust\/hg-cpython\/src\/copy_tracing.rs","diffId":"24617","author":"SimonSapin","id":"149254","dateCreated":"1611334107","dateModified":"1611334107"},{"type":"inline","comment":"This was a pre-existing comment, the previous commit only moved it around. But yeah I could have included this change in the previous commit.","replyTo":"149196","isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hg-cpython\/src\/copy_tracing.rs","diffId":"24617","author":"SimonSapin","id":"149253","dateCreated":"1611334107","dateModified":"1611334107"},{"type":"update","diffId":"25220","author":"SimonSapin","id":"149250","dateCreated":"1611333801","dateModified":"1611333801"},{"type":"inline","comment":"This will not honor the `RAYON_NUM_THREADS` environment variable that we use to contain the number of threads in tests, but also technically for users as an implementation detail. Should we use `rayon` threads here so as to have the same threadpool everywhere?","replyTo":null,"isNewFile":"1","line":"78","lineLength":"0","path":"rust\/hg-cpython\/src\/copy_tracing.rs","diffId":"24617","author":"Alphare","id":"149197","dateCreated":"1611309530","dateModified":"1611309530"},{"type":"inline","comment":"This is a better comment, I almost said something on the last commit","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hg-cpython\/src\/copy_tracing.rs","diffId":"24617","author":"Alphare","id":"149196","dateCreated":"1611309530","dateModified":"1611309530"},{"type":"update","diffId":"24617","author":"SimonSapin","id":"146123","dateCreated":"1609942348","dateModified":"1609942348"}],"dateCreated":"1609942348","dateModified":"1611465803","status":"Needs Review"},{"id":"9855","callsign":"HG","title":"histedit: rip out mysterious catch-all ignore curses.error handler","author":"durin42","summary":"I have no idea why this was here, and ripping it out doesn't obviously\nbreak anything for me (tests all pass, I can poke around chistedit UI\na bit without issue), so I'm thinking we should rip it out and see if\nwe get bug reports.","testPlan":"","lineCount":"109","dependsOn":["9854"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25231","author":"durin42","id":"149312","dateCreated":"1611348372","dateModified":"1611348372"}],"dateCreated":"1611348372","dateModified":"1611348372","status":"Needs Review"},{"id":"9854","callsign":"HG","title":"histedit: notice when the main window underflows height and abort","author":"durin42","summary":"If you try to have a 13-line-tall terminal and use curses histedit, it\nfails by spinning in an infinite loop due to the catch-all ignore of\ncurses errors on line 1682 of histedit.py. We should also fix that\ncatch-all ignore of curses errors (what other demons lurk here, I\nwonder?) but we can trivially catch this case and guide the user to a\nhappy path. We've seen this mostly in IDE users that have a tendency\nto have really tiny embedded terminal windows.","testPlan":"","lineCount":"11","dependsOn":["9853"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25230","author":"durin42","id":"149304","dateCreated":"1611348369","dateModified":"1611348369"}],"dateCreated":"1611348369","dateModified":"1611348372","status":"Needs Review"},{"id":"9853","callsign":"HG","title":"histedit: don't assign to _ for unused values","author":"durin42","summary":"I don't know what this ignored value is, but we need to not clobber\nthe _() function from gettext, or we get mysterious crashes instead of\ninternationalizing some strings in my upcoming patches.","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25229","author":"durin42","id":"149298","dateCreated":"1611348365","dateModified":"1611348365"}],"dateCreated":"1611348365","dateModified":"1611348369","status":"Needs Review"},{"id":"9686","callsign":"HG","title":"copies-rust: send PyBytes values back be dropped ino the parent thread","author":"SimonSapin","summary":"\u2026 instead of acquiring the GIL in the Rust thread in the Drop impl\n\nThis commit is based on the premise that crossbeam-channel\nwith unbounded send and non-blocking receive is faster than\na contended GIL, but that remains to be measured.","testPlan":"","lineCount":"47","dependsOn":["9685"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"149205","dateCreated":"1611310515","dateModified":"1611310515"},{"type":"update","diffId":"24619","author":"SimonSapin","id":"146139","dateCreated":"1609942358","dateModified":"1609942358"}],"dateCreated":"1609942358","dateModified":"1611335800","status":"Needs Review"},{"id":"9685","callsign":"HG","title":"copies-rust: introduce PyBytesWithData to reduce GIL requirement","author":"SimonSapin","summary":"See explanations in new doc-comments.","testPlan":"","lineCount":"80","dependsOn":["9684"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"149237","dateCreated":"1611331213","dateModified":"1611331213"},{"type":"inline","comment":"No. `PhantomData<Foo>` is purely type-level: it would influence the struct in terms of `auto` traits etc. without actually having a value of `Foo`.\n\nHere we do have a value of `PyBytes` pointing to a specific Python object, and want to eventually call its destructor but not as long as `PyBytesWithData::data` can still be called.","replyTo":"149199","isNewFile":"1","line":"29","lineLength":"0","path":"rust\/hg-cpython\/src\/copy_tracing.rs","diffId":"24618","author":"SimonSapin","id":"149231","dateCreated":"1611324356","dateModified":"1611324356"},{"type":"inline","comment":"Should that be `PhantomData<PyBytes>`?","replyTo":null,"isNewFile":"1","line":"29","lineLength":"0","path":"rust\/hg-cpython\/src\/copy_tracing.rs","diffId":"24618","author":"Alphare","id":"149199","dateCreated":"1611310043","dateModified":"1611310043"},{"type":"update","diffId":"24618","author":"SimonSapin","id":"146131","dateCreated":"1609942353","dateModified":"1609942353"}],"dateCreated":"1609942353","dateModified":"1611335799","status":"Needs Review"},{"id":"9683","callsign":"HG","title":"copies-rust: split up combine_changeset_copies function into a struct","author":"SimonSapin","summary":"\u2026 such that each iteration of its former loop is now a method call,\nwith the caller driving the loop.\n\nThis entirely removes the need for the `DataHolder` hack:\nthe method now takes a `ChangedFiles<'_>` parameter that borrows\na bytes buffer that can be owned by the caller\u2019s stack frame,\njust for the duration of that call.","testPlan":"","lineCount":"208","dependsOn":["9682"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"update","diffId":"25219","author":"SimonSapin","id":"149249","dateCreated":"1611333796","dateModified":"1611333796"},{"type":"inline","comment":"This should be a docstring, same goes for `finish`","replyTo":null,"isNewFile":"1","line":"388","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24616","author":"Alphare","id":"149187","dateCreated":"1611308922","dateModified":"1611308922"},{"type":"accept","author":"Alphare","id":"149186","dateCreated":"1611308922","dateModified":"1611308922"},{"type":"update","diffId":"24616","author":"SimonSapin","id":"146115","dateCreated":"1609942342","dateModified":"1609942342"}],"dateCreated":"1609942342","dateModified":"1611335797","status":"Needs Review"},{"id":"9844","callsign":"HG","title":"revlogv2: allow upgrading to v2","author":"Alphare","summary":"Revlogv2 implies sidedata.\nRight now sidedata is not really used in production, and Revlogv2 will be used\nfor the first production-ready version of sidedata support.","testPlan":"","lineCount":"117","dependsOn":["9843"],"reviewers":[],"ccs":["pulkit","mercurial-patches"],"actions":[{"type":"inline","comment":"A part of this seems like an unrelated change.","replyTo":null,"isNewFile":"1","line":"1257","lineLength":"0","path":"mercurial\/configitems.py","diffId":"25186","author":"pulkit","id":"149248","dateCreated":"1611333754","dateModified":"1611333754"},{"type":"update","diffId":"25186","author":"Alphare","id":"149011","dateCreated":"1611175536","dateModified":"1611175536"}],"dateCreated":"1611175536","dateModified":"1611333754","status":"Needs Review"},{"id":"9812","callsign":"HG","title":"tests: demonstrate a case where a corrupt tag cache causes an abort","author":"mharbison72","summary":"I happened to hit this trying to cover other cases around valid vs missing\nentries.  I have no idea if this is something that could occur more naturally\n(similar to how a missing file node in `hgtagsfnodes1` can occur after a strip).\nThere is a test just above this added in f5a7cf0adb12 mentioning it \"overwrites\nthe junk\", though that tests truncation instead of actual garbage.\n\nBut since this is just a cache, it probably shouldn't abort with a cryptic\nmessage like this.  The two options I see both have downsides- either rebuild\nthe cache (and potentially take a long time), or hint to the user to run a debug\ncommand.","testPlan":"","lineCount":"43","dependsOn":["9811"],"reviewers":[],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":">>! In D9812#149224, @mharbison72 wrote:\n> Even that would be tricky because at least for the problem I\u2019m trying to solve, you have to delete the cache before rebuilding it. Otherwise, you still get the wrong answer (for the thg problem). It makes me wonder if there are other issues with rebuilding an existing cache. If you\u2019re going to spend the time rebuilding, I guess it should be from scratch. But then aborting it should restore the original cache.\n\nSure, I was expecting a rebuild from scratch in a separate file with an atomic rename at the very end, so aborting would still work.","author":"Alphare","id":"149225","dateCreated":"1611322820","dateModified":"1611322820"},{"type":"comment","comment":">>! In D9812#149217, @Alphare wrote:\n> Maybe rebuilding the cache with a warning that it's being rebuilt while saying that they can abort, since I'm assuming rebuilding the cache is atomic?\n\nEven that would be tricky because at least for the problem I\u2019m trying to solve, you have to delete the cache before rebuilding it. Otherwise, you still get the wrong answer (for the thg problem). It makes me wonder if there are other issues with rebuilding an existing cache. If you\u2019re going to spend the time rebuilding, I guess it should be from scratch. But then aborting it should restore the original cache.\n","author":"mharbison72","id":"149224","dateCreated":"1611322740","dateModified":"1611322740"},{"type":"comment","comment":"Maybe rebuilding the cache with a warning that it's being rebuilt while saying that they can abort, since I'm assuming rebuilding the cache is atomic?","author":"Alphare","id":"149217","dateCreated":"1611311720","dateModified":"1611311720"},{"type":"update","diffId":"25090","author":"mharbison72","id":"148466","dateCreated":"1610920487","dateModified":"1610920487"}],"dateCreated":"1610920487","dateModified":"1611322820","status":"Needs Review"},{"id":"9811","callsign":"HG","title":"tagcache: distinguish between invalid and missing entries","author":"mharbison72","summary":"The TortoiseHg repo has typically not had a newly applied tag accessible by name\nfor recent releases, for unknown reasons.  Deleting and rebuilding the tag cache\ndoesn't fix it, though deleting the cache and running `hg log -r $new_tag` does.\nEventually the situation does sort itself out for new clones from the server.\nIn an effort to figure out what the issue is, Pierre-Yves David suggested\nlisting these entries in the debug output more specifically.\n\nThis isn't complete yet- the second test change that says \"missing\" is more like\n\"invalid\", since it was truncated.  The problem there is the code that reads the\nraw array truncates any partial records and then fills it with 0xFF, which\nsignifies that it is missing.  As a side note, that means the check for the\nlength when validating an existing entry never fails.","testPlan":"","lineCount":"54","dependsOn":[],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":"I'm always uncomfortable with a function that returns a value, `None` and `False`... but I suppose that for performance reasons we can't really do better. Where are your Rust enums when you need them? ;)","author":"Alphare","id":"149215","dateCreated":"1611311158","dateModified":"1611311158"},{"type":"accept","author":"Alphare","id":"149214","dateCreated":"1611311158","dateModified":"1611311158"},{"type":"update","diffId":"25089","author":"mharbison72","id":"148460","dateCreated":"1610920484","dateModified":"1610920484"}],"dateCreated":"1610920484","dateModified":"1611311158","status":"Needs Review"},{"id":"9682","callsign":"HG","title":"copies-rust: extract generic map merge logic from merge_copies_dict","author":"SimonSapin","summary":"This deduplicates the copy-tracing-specific logic","testPlan":"","lineCount":"377","dependsOn":["9656"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":"Thanks for the refactor, the comments are also clearer this way.","author":"Alphare","id":"149184","dateCreated":"1611308311","dateModified":"1611308311"},{"type":"accept","author":"Alphare","id":"149183","dateCreated":"1611308311","dateModified":"1611308311"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146596","dateCreated":"1610147777","dateModified":"1610147777"},{"type":"update","diffId":"24682","author":"baymax","id":"146595","dateCreated":"1610147777","dateModified":"1610147777"},{"type":"update","diffId":"24615","author":"SimonSapin","id":"146107","dateCreated":"1609942337","dateModified":"1609942337"}],"dateCreated":"1609942337","dateModified":"1611308311","status":"Needs Review"},{"id":"9834","callsign":"HG","title":"black: merge config into main pyproject.toml now that we have it","author":"durin42","summary":"This means that naive contributors who just run `black` on a source file\nwill get reasonable behavior as long as they have a recent black. Yay!","testPlan":"","lineCount":"34","dependsOn":["9833"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":"It was quite annoying when we first started using black, this should be better!","author":"Alphare","id":"149181","dateCreated":"1611306198","dateModified":"1611306198"},{"type":"accept","author":"Alphare","id":"149180","dateCreated":"1611306198","dateModified":"1611306198"},{"type":"update","diffId":"25156","author":"durin42","id":"148857","dateCreated":"1611079403","dateModified":"1611079403"}],"dateCreated":"1611079403","dateModified":"1611306198","status":"Needs Review"},{"id":"9833","callsign":"HG","title":"pyproject: add config file","author":"durin42","summary":"This will tell pip et al to call our setup.py for the majority of\npackaging concerns, but also gives us a place to put standard config\nstuff like black.","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"149178","dateCreated":"1611306154","dateModified":"1611306154"},{"type":"update","diffId":"25155","author":"durin42","id":"148851","dateCreated":"1611079400","dateModified":"1611079400"}],"dateCreated":"1611079400","dateModified":"1611306154","status":"Needs Review"},{"id":"9677","callsign":"HG","title":"upgrade: use copy+delete instead of rename while creating backup","author":"pulkit","summary":"A lot of times, we do an upgrade operation which does not touches all the parts\nof the stores. But right not, we have a blind logic which processes everything.\nTo selectively upgrade parts of repository, we need to persist existing data\nwhich is untouched.\n\nHowever while creating current repository backup, we rename the whole store\nleaving no option to persist untouched files.\n\nWe switch to copy+delete so that we can only delete data files which are changed\nby the operation and leave rest untouched.","testPlan":"","lineCount":"40","dependsOn":[],"reviewers":["marmoute"],"ccs":["mharbison72","ulrickaka","marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"Dropping this from stack for now to focus on getting other work pushed.","author":"pulkit","id":"149113","dateCreated":"1611240131","dateModified":"1611240131"},{"type":"plan-changes","author":"pulkit","id":"149112","dateCreated":"1611240131","dateModified":"1611240131"},{"type":"update","diffId":"24849","author":"pulkit","id":"147549","dateCreated":"1610628858","dateModified":"1610628858"},{"type":"comment","comment":"Note: that renaming a directory is instantaneous on any descent file system. copying full hierarchy is not.\n\nI am afraid your explanation is now confusing me. Can you try to explain what this patch is doing again ? ","author":"marmoute","id":"147388","dateCreated":"1610572678","dateModified":"1610572678"},{"type":"comment","comment":">>! In D9677#147172, @marmoute wrote:\n>>>! In D9677#147085, @mharbison72 wrote:\n>>>>! In D9677#146367, @pulkit wrote:\n>>>>>! In D9677#146243, @marmoute wrote:\n>>>> As pointed in a pa previous comment, this is problematic, because this does not preserve the same consistency as the previous code\n>>> \n>>> While the copy consistency can be maintained here, future changes (WIP) will break the consistency more. In upcoming work, we want to only touch parts of repository which needs to be updated. This will lead us to do selectively moving data from the upgraded repository to the current one.\n>> \n>> @marmoute are you OK with this explanation?\n> \n> Not at all :-)\n> \n> Currently we have:\n> 1) a fully consistent repository in place (while the upgrade run)\n> 2) a missing store during a split second (old store was rename)\n> 3) a fully consistent repository in place (the upgraded store was rename in place)\n> \n> The process ensure a very narrow inconsistency window and a very clear invalid state \"the store is either valid or missing.\"\n> \n> The change in this part move the (2) step to a much longer operation where elements get copied one by one. As a result we get a much longer window of inconsistency with a much wonkier inconsistency state as we get \"mixed\" files within the resulting store.\n\nNope, this patch does not do that. We have three stores here: backupstore (containing backup of current store), current store and upgraded store. Below is comparison of split second as part 2) mentioned above.\n\nBefore:\n\n1) Move current store to backup store\n2) Move upgraded store to current store\n\nStore inconsistency starts when step 1) starts and remains till step 2) finishes since both are move operation.\n\nAfter this patch:\n\n1) Copy current store to backup store\n2) Move upgraded store to current store\n\nIn this one, store inconsistency happens only at step 2) since step 1) is a copy.\n\nSo, this patch reduces the time when store was inconsistent.","author":"pulkit","id":"147240","dateCreated":"1610553408","dateModified":"1610553408"},{"type":"comment","comment":">>! In D9677#147085, @mharbison72 wrote:\n>>>! In D9677#146367, @pulkit wrote:\n>>>>! In D9677#146243, @marmoute wrote:\n>>> As pointed in a pa previous comment, this is problematic, because this does not preserve the same consistency as the previous code\n>> \n>> While the copy consistency can be maintained here, future changes (WIP) will break the consistency more. In upcoming work, we want to only touch parts of repository which needs to be updated. This will lead us to do selectively moving data from the upgraded repository to the current one.\n> \n> @marmoute are you OK with this explanation?\n\nNot at all :-)\n\nCurrently we have:\n1) a fully consistent repository in place (while the upgrade run)\n2) a missing store during a split second (old store was rename)\n3) a fully consistent repository in place (the upgraded store was rename in place)\n\nThe process ensure a very narrow inconsistency window and a very clear invalid state \"the store is either valid or missing.\"\n\nThe change in this part move the (2) step to a much longer operation where elements get copied one by one. As a result we get a much longer window of inconsistency with a much wonkier inconsistency state as we get \"mixed\" files within the resulting store.\n\nSo overall this change is going in the wrong direction.\n\nWe are currently looking for lighter upgrade for 2 feature \"persistent nodemap\" and \"share-safe\". And I don't think either of them need this kind of change. A upgrade processs for persistent nodemap could be:\n\n  # write new persistent nodemaps (data file, then docket) that nobody will read without the requirements. \n  # add the new requirement\n\nThe downgrade being the reverse (remove the requirement, remove the nodemaps)\n\nAnd something similar could be done for the share-safe upgrade\n\n  # write a new `.hg\/store\/requirements` that nobody will read yet\n  # rewrite `.hg\/requirements`","author":"marmoute","id":"147172","dateCreated":"1610534053","dateModified":"1610534053"},{"type":"reject","author":"marmoute","id":"147171","dateCreated":"1610534053","dateModified":"1610534053"},{"type":"update","diffId":"24774","author":"pulkit","id":"147170","dateCreated":"1610533896","dateModified":"1610533896"},{"type":"comment","comment":">>! In D9677#146367, @pulkit wrote:\n>>>! In D9677#146243, @marmoute wrote:\n>> As pointed in a pa previous comment, this is problematic, because this does not preserve the same consistency as the previous code\n> \n> While the copy consistency can be maintained here, future changes (WIP) will break the consistency more. In upcoming work, we want to only touch parts of repository which needs to be updated. This will lead us to do selectively moving data from the upgraded repository to the current one.\n\n@marmoute are you OK with this explanation?\n\nMy question is, would it be better to hardlink and then delete to avoid the copy overhead?  (Of course not every filesystem supports that, but I think it falls back to a copy in that case.)","author":"mharbison72","id":"147085","dateCreated":"1610500850","dateModified":"1610500850"},{"type":"update","diffId":"24650","author":"pulkit","id":"146401","dateCreated":"1610131519","dateModified":"1610131519"},{"type":"comment","comment":">>! In D9677#146243, @marmoute wrote:\n> As pointed in a pa previous comment, this is problematic, because this does not preserve the same consistency as the previous code\n\nWhile the copy consistency can be maintained here, future changes (WIP) will break the consistency more. In upcoming work, we want to only touch parts of repository which needs to be updated. This will lead us to do selectively moving data from the upgraded repository to the current one.","author":"pulkit","id":"146367","dateCreated":"1610123806","dateModified":"1610123806"},{"type":"comment","comment":"As pointed in a pa previous comment, this is problematic, because this does not preserve the same consistency as the previous code","author":"marmoute","id":"146243","dateCreated":"1610074367","dateModified":"1610074367"},{"type":"reject","author":"marmoute","id":"146242","dateCreated":"1610074367","dateModified":"1610074367"},{"type":"comment","comment":"[[ http:\/\/www.essayempire.co.uk\/custom-essay-writing-service | Help With Essay ]]\nfrom the Academic Experts. Our essay writing service is designed to get you the extra help you need in completing your next university essay","author":"ulrickaka","id":"146070","dateCreated":"1609873493","dateModified":"1609873493"},{"type":"comment","comment":"I worried about having a much wider inconsistency window if we don't use rename. I'll have a deeper look later.","author":"marmoute","id":"145999","dateCreated":"1609837839","dateModified":"1609837839"},{"type":"update","diffId":"24564","author":"pulkit","id":"145922","dateCreated":"1609432989","dateModified":"1609432989"}],"dateCreated":"1609432989","dateModified":"1611240131","status":"Changes Planned"},{"id":"8504","callsign":"HG","title":"diff: add experimental support for \"merge diffs\"","author":"durin42","summary":"This does not currently pass tests, because in-memory merge can't\nrepresent conflicts, which this requires. I intend to shave that yak\nnext.\n\nPublishing the patch now as motivation for the preceding patches, and\nin case someone has feedback on the approach.","testPlan":"","lineCount":"139","dependsOn":[],"reviewers":["marmoute"],"ccs":["pulkit","marmoute","martinvonz","mercurial-patches"],"actions":[{"type":"comment","comment":"Looks good to me but the commit description needs to be updated and an entry in `relnotes\/next` will be helpful.","author":"pulkit","id":"149055","dateCreated":"1611227937","dateModified":"1611227937"},{"type":"plan-changes","author":"durin42","id":"148891","dateCreated":"1611082507","dateModified":"1611082507"},{"type":"update","diffId":"25160","author":"durin42","id":"148889","dateCreated":"1611082488","dateModified":"1611082488"},{"type":"plan-changes","author":"durin42","id":"137368","dateCreated":"1601664445","dateModified":"1601664445"},{"type":"update","diffId":"23028","author":"durin42","id":"137347","dateCreated":"1601664333","dateModified":"1601664333"},{"type":"comment","comment":"According to IRC discussion, this series is not ready for review, so moving it out of yadda.","author":"marmoute","id":"132184","dateCreated":"1596211431","dateModified":"1596211431"},{"type":"reject","author":"marmoute","id":"132183","dateCreated":"1596211431","dateModified":"1596211431"},{"type":"update","diffId":"21596","author":"durin42","id":"128796","dateCreated":"1591735924","dateModified":"1591735924"},{"type":"comment","comment":"I like the idea a lot :-)","author":"marmoute","id":"128627","dateCreated":"1591639633","dateModified":"1591639633"},{"type":"update","diffId":"21515","author":"durin42","id":"128255","dateCreated":"1590697637","dateModified":"1590697637"},{"type":"update","diffId":"21449","author":"durin42","id":"127892","dateCreated":"1589839719","dateModified":"1589839719"},{"type":"inline","comment":"How about calling these \"pctx1\" and \"pctx2\" instead so the same name doesn't change meaning and so you don't have to reassign \"ctx2\"?","replyTo":null,"isNewFile":"1","line":"2501","lineLength":"0","path":"mercurial\/commands.py","diffId":"21344","author":"martinvonz","id":"127304","dateCreated":"1589252257","dateModified":"1589252257"},{"type":"inline","comment":"Like the test case you added below. There, base is \"8\", left is \"z\", right is \"y\", and resolved is \"z\", if I'm reading that right.","replyTo":"127274","isNewFile":"1","line":"187","lineLength":"0","path":"tests\/test-diff-change.t","diffId":"21318","author":"martinvonz","id":"127303","dateCreated":"1589252257","dateModified":"1589252257"},{"type":"comment","comment":"For anyone curious what's left, the test currently fails like this:\n\n```\n--- tests\/test-diff-change.t\n+++ tests\/test-diff-change.t.err\n@@ -241,9 +241,15 @@\n   ->>>>>>> other: d9e7de69eac3 - test: new file\n    9\n    10\n+  diff -r 5010caab09f6 new-file-p2.txt\n+  --- \/dev\/null\tThu Jan 01 00:00:00 1970 +0000\n+  +++ b\/new-file-p2.txt\tThu Jan 01 00:00:00 1970 +0000\n+  @@ -0,0 +1,1 @@\n+  +this file is new in p2 of the merge\n \n There must _NOT_ be a .hg\/merge directory leftover.\n   $ test ! -e .hg\/merge\n-\n-\n-  $ cd ..\n+  [1]\n+\n+\n+  $ cd ..\n```","author":"durin42","id":"127289","dateCreated":"1589237340","dateModified":"1589237340"},{"type":"update","diffId":"21344","author":"durin42","id":"127285","dateCreated":"1589237313","dateModified":"1589237313"},{"type":"update","diffId":"21342","author":"durin42","id":"127275","dateCreated":"1589235716","dateModified":"1589235716"},{"type":"inline","comment":"Not sure what you mean. Can you elaborate?","replyTo":"127228","isNewFile":"1","line":"187","lineLength":"0","path":"tests\/test-diff-change.t","diffId":"21318","author":"durin42","id":"127274","dateCreated":"1589233597","dateModified":"1589233597"},{"type":"inline","comment":"Wow, that feels obvious in hindsight. And then we can also default-true when tweakdefaults is on.","replyTo":"127226","isNewFile":"1","line":"2413","lineLength":"0","path":"mercurial\/commands.py","diffId":"21318","author":"durin42","id":"127273","dateCreated":"1589233597","dateModified":"1589233597"},{"type":"update","diffId":"21341","author":"durin42","id":"127271","dateCreated":"1589232873","dateModified":"1589232873"},{"type":"inline","comment":"We should have at least one test showing a \"four-way diff\" with base, left, right, and resolved states.","replyTo":null,"isNewFile":"1","line":"187","lineLength":"0","path":"tests\/test-diff-change.t","diffId":"21318","author":"martinvonz","id":"127228","dateCreated":"1588955093","dateModified":"1588955093"},{"type":"inline","comment":"Want to set a specific merge tool here while running this?","replyTo":null,"isNewFile":"1","line":"2512","lineLength":"0","path":"mercurial\/commands.py","diffId":"21318","author":"martinvonz","id":"127227","dateCreated":"1588955093","dateModified":"1588955093"},{"type":"inline","comment":"How about making this boolean-valued instead? I'd expect `hg diff --merge -c <some merge commit>` to work. That will also make it easy to provide a config option to always enable it. (I don't ever want the current behavior for `-c` with merge commits.)","replyTo":null,"isNewFile":"1","line":"2413","lineLength":"0","path":"mercurial\/commands.py","diffId":"21318","author":"martinvonz","id":"127226","dateCreated":"1588955093","dateModified":"1588955093"},{"type":"inline","comment":"Or should we allow non-merge commits so one can always pass `--merge` without thinking (e.g. in `[defaults]`)?","replyTo":null,"isNewFile":"1","line":"2506","lineLength":"1","path":"mercurial\/commands.py","diffId":"21318","author":"martinvonz","id":"127225","dateCreated":"1588955093","dateModified":"1588955093"},{"type":"inline","comment":"Seems like it would be cleaner to combine these two.","replyTo":null,"isNewFile":"1","line":"2503","lineLength":"15","path":"mercurial\/commands.py","diffId":"21318","author":"martinvonz","id":"127224","dateCreated":"1588955093","dateModified":"1588955093"},{"type":"comment","comment":"Looking forward to using this!","author":"martinvonz","id":"127223","dateCreated":"1588955093","dateModified":"1588955093"},{"type":"update","diffId":"21318","author":"durin42","id":"127159","dateCreated":"1588886767","dateModified":"1588886767"}],"dateCreated":"1588886767","dateModified":"1611227937","status":"Changes Planned"},{"id":"9846","callsign":"HG","title":"cext: add support for revlogv2","author":"Alphare","summary":"","testPlan":"","lineCount":"135","dependsOn":["9845"],"reviewers":["indygreg"],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25188","author":"Alphare","id":"149026","dateCreated":"1611175548","dateModified":"1611175548"}],"dateCreated":"1611175548","dateModified":"1611175549","status":"Needs Review"},{"id":"9845","callsign":"HG","title":"bitmanipulation: add utils to read\/write bigendian 64bit integers","author":"Alphare","summary":"","testPlan":"","lineCount":"37","dependsOn":["9844"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25187","author":"Alphare","id":"149019","dateCreated":"1611175542","dateModified":"1611175542"}],"dateCreated":"1611175542","dateModified":"1611175549","status":"Needs Review"},{"id":"9721","callsign":"HG","title":"convert: option to set date and time for svn commits","author":"nslsrv","summary":"Converting to subversion repository is not preserving original commit dates as\nit may break some subversion functionality if commit dates are not monotonically\nincreasing.\n\nThis patch adds `convert.svn.dangerous-set-commit-dates` configuration option\nto change this behaviour and enable commit dates convertion for those who want\nto take risks.\n\nSubversion always uses commit dates with UTC timezone, so only timestamps\nare used.\n\nTest `test-convert-svn-sink.t` uses `svnxml.py` script to dump history of svn\nrepositories. Atm the script is not printing `date` field from svn log. This\npatch changes this to allow checks on correctness of date and time convertion.\n\nDocumentation is updated. Additional test case is added to test commit dates\nconvertion.","testPlan":"","lineCount":"183","dependsOn":[],"reviewers":[],"ccs":["durin42","mercurial-patches"],"actions":[{"type":"comment","comment":"Ping someone else please - I'm busy with other things this week. :(","author":"durin42","id":"148892","dateCreated":"1611083550","dateModified":"1611083550"},{"type":"comment","comment":"@durin42 Should I ask you or anybody else to review? No problem with waiting, just not sure.","author":"nslsrv","id":"148864","dateCreated":"1611081536","dateModified":"1611081536"},{"type":"comment","comment":"I decided to simplify things and made an option to enable\/disable date setting altogether. I've addressed the comments about option naming, documented the need for pre-revprop-change hook modification and made the hook generation more flexible for local repo case.","author":"nslsrv","id":"146861","dateCreated":"1610486672","dateModified":"1610486672"},{"type":"update","diffId":"24722","author":"nslsrv","id":"146857","dateCreated":"1610486401","dateModified":"1610486401"},{"type":"inline","comment":"I don't know that I'd bother with the more complicated version. I do think it makes sense to have the date-propsetting off by default (the hg:whatever ones are fine - they're harmless).\n\nGood catch on this failing-working if propsets fail. I guess that's by design. Probably still should document the svn-date-editing thing requiring the hook because otherwise that's a mysterious bug report in 3y waiting to happen IMO.","replyTo":"146772","isNewFile":"1","line":"504","lineLength":"0","path":"hgext\/convert\/__init__.py","diffId":"24710","author":"durin42","id":"146823","dateCreated":"1610465830","dateModified":"1610465830"},{"type":"inline","comment":"If there's no pre-revprop-change hook than propsetting would fail completely, not only for svn:date, but also for hg:convert-rev and hg:convert-branch. It would work as a natural barrier, since propset retcodes are not checked.\n\nThe setting being proposed here is not for enabling propsetting itself, but rather for controlling its behavior making it \"safe\" or \"non-safe\".\n\nBy now I assume that monotonically increasing dates is a good default if propsetting itself is allowed on the server. Do you think that it's better to have propsetting disabled by default?\n\nI'm preparing the patch that checks the last revision date, which makes the code even more complex. Maybe it's time to shift back to simplier solution and make an option to just enable\/disable date propsetting itself.","replyTo":"146769","isNewFile":"1","line":"504","lineLength":"0","path":"hgext\/convert\/__init__.py","diffId":"24710","author":"nslsrv","id":"146772","dateCreated":"1610413667","dateModified":"1610413667"},{"type":"inline","comment":"I'd rather this had a scarier name, like `allow-setting-dates-i-understand-this-can-break-some-svn-behavior-and-read-the-docs`. Also, modern convention these days is to separate words with dashes in config knobs to make them easier to read. :)","replyTo":null,"isNewFile":"1","line":"501","lineLength":"0","path":"hgext\/convert\/__init__.py","diffId":"24710","author":"durin42","id":"146770","dateCreated":"1610410279","dateModified":"1610410279"},{"type":"inline","comment":"Extra caveats are required here, notably that per http:\/\/svnbook.red-bean.com\/en\/1.7\/svn.ref.reposhooks.pre-revprop-change.html if the pre-revprop-change hook is absent (the default) on the server then this option must remain disabled.","replyTo":null,"isNewFile":"1","line":"504","lineLength":"0","path":"hgext\/convert\/__init__.py","diffId":"24710","author":"durin42","id":"146769","dateCreated":"1610410279","dateModified":"1610410279"},{"type":"inline","comment":"I guess it's wrong for incremental conversion: it must be initialized with the last svn commit date, if destination svn repository is not empty.","replyTo":null,"isNewFile":"1","line":"1489","lineLength":"0","path":"hgext\/convert\/subversion.py","diffId":"24710","author":"nslsrv","id":"146767","dateCreated":"1610407995","dateModified":"1610407995"},{"type":"comment","comment":"Just noticed that incremental conversion is not covered by the patch.","author":"nslsrv","id":"146766","dateCreated":"1610407995","dateModified":"1610407995"},{"type":"plan-changes","author":"nslsrv","id":"146765","dateCreated":"1610407995","dateModified":"1610407995"},{"type":"comment","comment":"Continuation of D9715.","author":"nslsrv","id":"146763","dateCreated":"1610405858","dateModified":"1610405858"},{"type":"update","diffId":"24710","author":"nslsrv","id":"146754","dateCreated":"1610405723","dateModified":"1610405723"}],"dateCreated":"1610405723","dateModified":"1611083550","status":"Needs Review"},{"id":"9828","callsign":"HG","title":"changelog: use revision number as the cache key internally","author":"marmoute","summary":"This allow both rev and node request to match the cache.","testPlan":"","lineCount":"9","dependsOn":["9827"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148751","dateCreated":"1610997273","dateModified":"1610997273"},{"type":"update","diffId":"25141","author":"baymax","id":"148750","dateCreated":"1610997273","dateModified":"1610997273"},{"type":"update","diffId":"25135","author":"marmoute","id":"148716","dateCreated":"1610993475","dateModified":"1610993475"}],"dateCreated":"1610993475","dateModified":"1610997273","status":"Needs Review"},{"id":"9827","callsign":"HG","title":"changelog: cache the latest `changelogrevision` access","author":"marmoute","summary":"This will speedup repeated call to the same data. Which can be common when\nwarming various cache after adding a revision.","testPlan":"","lineCount":"9","dependsOn":["9826"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148749","dateCreated":"1610997271","dateModified":"1610997271"},{"type":"update","diffId":"25140","author":"baymax","id":"148748","dateCreated":"1610997271","dateModified":"1610997271"},{"type":"update","diffId":"25134","author":"marmoute","id":"148708","dateCreated":"1610993471","dateModified":"1610993471"}],"dateCreated":"1610993471","dateModified":"1610997271","status":"Needs Review"},{"id":"9826","callsign":"HG","title":"callback: add a new_cl_rev_callback","author":"marmoute","summary":"This will be useful for consistency and cache warming.","testPlan":"","lineCount":"19","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148746","dateCreated":"1610997270","dateModified":"1610997270"},{"type":"update","diffId":"25139","author":"baymax","id":"148744","dateCreated":"1610997270","dateModified":"1610997270"},{"type":"update","diffId":"25133","author":"marmoute","id":"148702","dateCreated":"1610993467","dateModified":"1610993467"}],"dateCreated":"1610993467","dateModified":"1610997270","status":"Needs Review"},{"id":"9796","callsign":"HG","title":"copies: add an devel option to trace all files","author":"marmoute","summary":"Filelog based copy tracing only trace copy for file that have been added. This\nis a trade off between skipping some rare copy case in exchange for avoiding\natrocious-to-the-point-of-unusable performance.\n\nThe changeset centric copy tracing does not need this trade off and naturally\ntrace all copy, include the one involving non-new files.\n\nIn order to ease the comparison from both algorithm, we add a small devel option\nto trace copy for all files in the target revisions.","testPlan":"","lineCount":"37","dependsOn":["9795"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148595","dateCreated":"1610978074","dateModified":"1610978074"},{"type":"update","diffId":"25108","author":"baymax","id":"148594","dateCreated":"1610978074","dateModified":"1610978074"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"147974","dateCreated":"1610762332","dateModified":"1610762332"},{"type":"update","diffId":"24922","author":"baymax","id":"147973","dateCreated":"1610762332","dateModified":"1610762332"},{"type":"update","diffId":"24919","author":"marmoute","id":"147968","dateCreated":"1610760245","dateModified":"1610760245"},{"type":"update","diffId":"24910","author":"marmoute","id":"147907","dateCreated":"1610752192","dateModified":"1610752192"}],"dateCreated":"1610752192","dateModified":"1610978074","status":"Needs Review"},{"id":"9795","callsign":"HG","title":"copies: simplify the conditional for _filter's case 3","author":"marmoute","summary":"The conditional is much simpler and the test are actually happier. This\nclarification of the conditional will also be necessary to properly support tracing\nmore renames in a coming changeset.","testPlan":"","lineCount":"13","dependsOn":["9794"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148593","dateCreated":"1610978073","dateModified":"1610978073"},{"type":"update","diffId":"25107","author":"baymax","id":"148592","dateCreated":"1610978073","dateModified":"1610978073"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"147972","dateCreated":"1610762328","dateModified":"1610762328"},{"type":"update","diffId":"24921","author":"baymax","id":"147971","dateCreated":"1610762328","dateModified":"1610762328"},{"type":"update","diffId":"24918","author":"marmoute","id":"147967","dateCreated":"1610760240","dateModified":"1610760240"},{"type":"comment","comment":"The graft code is doing something wonky. Issue fixed.","author":"marmoute","id":"147954","dateCreated":"1610760175","dateModified":"1610760175"},{"type":"comment","comment":"this makes `test-rebase-rename.t` unhappy, investigating","author":"marmoute","id":"147953","dateCreated":"1610757159","dateModified":"1610757159"},{"type":"plan-changes","author":"marmoute","id":"147952","dateCreated":"1610757159","dateModified":"1610757159"},{"type":"update","diffId":"24909","author":"marmoute","id":"147899","dateCreated":"1610752187","dateModified":"1610752187"}],"dateCreated":"1610752187","dateModified":"1610978073","status":"Needs Review"},{"id":"9794","callsign":"HG","title":"copies: clarify which case some conditional are handling","author":"marmoute","summary":"This make the function a bit clearer. The middle conditional get no label\nbecause we about about to remove it. See next changeset for details.","testPlan":"","lineCount":"4","dependsOn":["9802"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148591","dateCreated":"1610978071","dateModified":"1610978071"},{"type":"update","diffId":"25106","author":"baymax","id":"148590","dateCreated":"1610978071","dateModified":"1610978071"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"147970","dateCreated":"1610762326","dateModified":"1610762326"},{"type":"update","diffId":"24920","author":"baymax","id":"147969","dateCreated":"1610762326","dateModified":"1610762326"},{"type":"update","diffId":"24917","author":"marmoute","id":"147963","dateCreated":"1610760235","dateModified":"1610760235"},{"type":"update","diffId":"24908","author":"marmoute","id":"147891","dateCreated":"1610752182","dateModified":"1610752182"}],"dateCreated":"1610752182","dateModified":"1610978071","status":"Needs Review"},{"id":"9802","callsign":"HG","title":"copies: explicitly filter out existing file in graftcopies","author":"marmoute","summary":"The `graftcopies` function does something very strange (maybe even wrong), it\ncalls `_filter` with a pair of changeset that does not match the one used to\ncompute the copies informations.\n\nWe are about to do some rework of `_filter` to make it closer to its documented\nintent and fix a couple of bug. This means some of the logic that only make\nsense for graft need to go somewhere else. We add the extra filtering with\nproper documentation to `graftcopies`.","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"148589","dateCreated":"1610978070","dateModified":"1610978070"},{"type":"update","diffId":"25105","author":"baymax","id":"148588","dateCreated":"1610978070","dateModified":"1610978070"},{"type":"update","diffId":"24916","author":"marmoute","id":"147956","dateCreated":"1610760231","dateModified":"1610760231"}],"dateCreated":"1610760230","dateModified":"1610978070","status":"Needs Review"},{"id":"9817","callsign":"HG","title":"relnote: remove the reference to `debugstrip`","author":"marmoute","summary":"The `debug` namespace is not intended for end user and advertising it is a path\nto confusion and trouble. I think we should wait for the `admin` namespace to\nexists and the command to be available as `admin--strip` before we advertise it.","testPlan":"","lineCount":"3","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"update","diffId":"25099","author":"marmoute","id":"148529","dateCreated":"1610961915","dateModified":"1610961915"}],"dateCreated":"1610961915","dateModified":"1610963830","status":"Needs Review"},{"id":"9726","callsign":"HG","title":"ci: use parallel matrices","author":"danchr","summary":"","testPlan":"","lineCount":"100","dependsOn":["9725"],"reviewers":[],"ccs":["marmoute","Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":"This looks very nice, but please coordinate with @Alphare who have been writing important change in this area too. (orthogonal, but conflicting) ","author":"marmoute","id":"147985","dateCreated":"1610771021","dateModified":"1610771021"},{"type":"comment","comment":":negative_squared_cross_mark: refresh by Heptapod after a failed CI run (:octopus: :heart:) https:\/\/foss.heptapod.net\/octobus\/mercurial-devel\/-\/pipelines\/16444","author":"baymax","id":"147686","dateCreated":"1610677124","dateModified":"1610677124"},{"type":"update","diffId":"24871","author":"baymax","id":"147685","dateCreated":"1610677124","dateModified":"1610677124"},{"type":"update","diffId":"24717","author":"danchr","id":"146807","dateCreated":"1610453275","dateModified":"1610453275"}],"dateCreated":"1610453275","dateModified":"1610771021","status":"Needs Review"},{"id":"9725","callsign":"HG","title":"ci: generate and report XML test results","author":"danchr","summary":"","testPlan":"","lineCount":"11","dependsOn":["9724"],"reviewers":[],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"This looks fine, but could you describe a bit what this is suppose to achieve and maybe provide a link to an example ?","author":"marmoute","id":"147983","dateCreated":"1610770973","dateModified":"1610770973"},{"type":"comment","comment":":negative_squared_cross_mark: refresh by Heptapod after a failed CI run (:octopus: :heart:) https:\/\/foss.heptapod.net\/octobus\/mercurial-devel\/-\/pipelines\/16444","author":"baymax","id":"147684","dateCreated":"1610677123","dateModified":"1610677123"},{"type":"update","diffId":"24870","author":"baymax","id":"147683","dateCreated":"1610677123","dateModified":"1610677123"},{"type":"update","diffId":"24716","author":"danchr","id":"146800","dateCreated":"1610453270","dateModified":"1610453270"}],"dateCreated":"1610453270","dateModified":"1610770973","status":"Needs Review"},{"id":"9724","callsign":"HG","title":"ci: build python wheels","author":"danchr","summary":"The wheels are merely attached to the job as artifacts. We could\nupload them to Heptapod or PyPI, but that's left for a possible followup.","testPlan":"","lineCount":"40","dependsOn":[],"reviewers":[],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"inline","comment":"Should we have an image based on `uay.io\/pypa\/${PLATFORM}` with this installed instead ?","replyTo":null,"isNewFile":"1","line":"118","lineLength":"0","path":"contrib\/heptapod-ci.yml","diffId":"24869","author":"marmoute","id":"147981","dateCreated":"1610770832","dateModified":"1610770832"},{"type":"comment","comment":"Do we want to build the wheel for every changeset ? or only build \"nightly\" build from default? (and tags! for tags !)\n\nWhat value do you expect if we run them for everything ?","author":"marmoute","id":"147980","dateCreated":"1610770832","dateModified":"1610770832"},{"type":"comment","comment":":negative_squared_cross_mark: refresh by Heptapod after a failed CI run (:octopus: :heart:) https:\/\/foss.heptapod.net\/octobus\/mercurial-devel\/-\/pipelines\/16444","author":"baymax","id":"147682","dateCreated":"1610677121","dateModified":"1610677121"},{"type":"update","diffId":"24869","author":"baymax","id":"147681","dateCreated":"1610677121","dateModified":"1610677121"},{"type":"update","diffId":"24715","author":"danchr","id":"146792","dateCreated":"1610453265","dateModified":"1610453265"}],"dateCreated":"1610453265","dateModified":"1610770832","status":"Needs Review"},{"id":"9727","callsign":"HG","title":"ci: report status to phabricator on failures","author":"danchr","summary":"","testPlan":"","lineCount":"22","dependsOn":["9726"],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"phabricator is inconstistent when it comes to updating diff (and printing associated message). So I fear we would end up in situation where a comment would be made to make a Diff as part of a failing run, without it being replaced by a positive message once test pass.\n\nSo -1 on this until it is fixed or proved to not happen.","author":"marmoute","id":"147977","dateCreated":"1610770681","dateModified":"1610770681"},{"type":"reject","author":"marmoute","id":"147976","dateCreated":"1610770681","dateModified":"1610770681"},{"type":"comment","comment":":negative_squared_cross_mark: refresh by Heptapod after a failed CI run (:octopus: :heart:) https:\/\/foss.heptapod.net\/octobus\/mercurial-devel\/-\/pipelines\/16444","author":"baymax","id":"147688","dateCreated":"1610677126","dateModified":"1610677126"},{"type":"update","diffId":"24872","author":"baymax","id":"147687","dateCreated":"1610677126","dateModified":"1610677126"},{"type":"comment","comment":":negative_squared_cross_mark: refresh by Heptapod after a failed CI run (:octopus: :heart:) https:\/\/foss.heptapod.net\/octobus\/mercurial-devel\/-\/pipelines\/15994","author":"baymax","id":"146822","dateCreated":"1610457108","dateModified":"1610457108"},{"type":"update","diffId":"24719","author":"baymax","id":"146821","dateCreated":"1610457108","dateModified":"1610457108"},{"type":"update","diffId":"24718","author":"danchr","id":"146814","dateCreated":"1610453280","dateModified":"1610453280"}],"dateCreated":"1610453280","dateModified":"1610770681","status":"Needs Revision"},{"id":"9765","callsign":"HG","title":"persistent-nodemap: enable the feature by default when using Rust","author":"marmoute","summary":"As discussed at the 5.6 sprint, we can make it enabled by default, but only for\nRust installation.","testPlan":"","lineCount":"22","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":"They are a large amout ot test to update for this change.","author":"marmoute","id":"147503","dateCreated":"1610599154","dateModified":"1610599154"},{"type":"plan-changes","author":"marmoute","id":"147502","dateCreated":"1610599154","dateModified":"1610599154"},{"type":"update","diffId":"24835","author":"marmoute","id":"147491","dateCreated":"1610597144","dateModified":"1610597144"}],"dateCreated":"1610597144","dateModified":"1610599154","status":"Changes Planned"},{"id":"9056","callsign":"HG","title":"fix: include adjacent blank lines in ranges to be fixed","author":"msuozzo","summary":"When you remove a statement in python and the two adjacent lines are blank,\nthis can create lint errors due to improper spacing. I'm sure this is also the\ncase with other whitespace-aware languages and file formats. The current fix\ncommand skips all removal diffs and so doesn't trigger the auto-formatting of\nthat whitespace.\n\nNet Cost:\n- Two extra line checks for all diffs and fix ranges that could be 1-2 lines\n  longer.\n- One extra fix range generated for each pure-removal diff.\nNet Benefit:\n- Whitespace-aware languages are able to format and resolve whitespace errors.","testPlan":"","lineCount":"205","dependsOn":[],"reviewers":["hooper"],"ccs":["pulkit","mercurial-patches"],"actions":[{"type":"comment","comment":">>! In D9056#147377, @hooper wrote:\n> The patch looks fine now.\n\nGreat!\n\n> \n> I still think we shouldn't go down the road of implementing formatting behavior abstractly on top of the actual formatters. Ideally, we would pass flags to the formatter that ask it to do the right language-aware thing at the byte\/line offset of a deletion. It's going to be awkward to support\/document this if\/when we get a solution like that.\n\nI agree in principle \/\/but\/\/ I think the lack of support for those features in actual formatters indicates that this config option will still provide meaningful value to users. If\/when popular formatters support this sort of adjacency detection, it may make sense to sunset this sort of feature but I'm not confident that will happen soon.","author":"msuozzo","id":"147389","dateCreated":"1610572876","dateModified":"1610572876"},{"type":"comment","comment":"The patch looks fine now.\n\nI still think we shouldn't go down the road of implementing formatting behavior abstractly on top of the actual formatters. Ideally, we would pass flags to the formatter that ask it to do the right language-aware thing at the byte\/line offset of a deletion. It's going to be awkward to support\/document this if\/when we get a solution like that.","author":"hooper","id":"147377","dateCreated":"1610569221","dateModified":"1610569221"},{"type":"comment","comment":"Bump","author":"msuozzo","id":"146708","dateCreated":"1610383620","dateModified":"1610383620"},{"type":"comment","comment":"Expanded the doctests a bit and factored out some of the index arithmetic.","author":"msuozzo","id":"145934","dateCreated":"1609568116","dateModified":"1609568116"},{"type":"update","diffId":"24566","author":"msuozzo","id":"145931","dateCreated":"1609568042","dateModified":"1609568042"},{"type":"update","diffId":"24565","author":"msuozzo","id":"145930","dateCreated":"1609567743","dateModified":"1609567743"},{"type":"inline","comment":"This is where you can add simple tests for the overlapping line ranges issue.\n\nYou might want to expand these test cases anyway, so we can be more confident we're not changing the behavior when the new config is off.","replyTo":null,"isNewFile":"1","line":"615","lineLength":"0","path":"hgext\/fix.py","diffId":"23292","author":"hooper","id":"138918","dateCreated":"1603492665","dateModified":"1603492665"},{"type":"inline","comment":"Sorry, I just realized this gets passed through unionranges() later on (to combine line ranges computed from multiple \"diff base\" commits). Not sure if we really need to ensure that this function returns non-overlapping ranges, but it seems like it might prevent mistakes later. The code is not strictly necessary here, though.","replyTo":null,"isNewFile":"1","line":"647","lineLength":"0","path":"hgext\/fix.py","diffId":"23292","author":"hooper","id":"138917","dateCreated":"1603492665","dateModified":"1603492665"},{"type":"inline","comment":"Reworded a bit. PTAL","replyTo":"138771","isNewFile":"1","line":"625","lineLength":"0","path":"hgext\/fix.py","diffId":"23265","author":"msuozzo","id":"138884","dateCreated":"1603402036","dateModified":"1603402036"},{"type":"comment","comment":"Okay the implementation itself looks better to me.\n\nAs for the multi-formatter considerations, I just don't think it should play a big role in whether this feature is worthwhile. This clearly addresses a configurability knob that didn't previously exist and I think that alone should dictate the viability of this patch.","author":"msuozzo","id":"138883","dateCreated":"1603402036","dateModified":"1603402036"},{"type":"update","diffId":"23292","author":"msuozzo","id":"138881","dateCreated":"1603401708","dateModified":"1603401708"},{"type":"inline","comment":"I still suggest combining adjacent\/overlapping ranges.","replyTo":null,"isNewFile":"1","line":"640","lineLength":"0","path":"hgext\/fix.py","diffId":"23265","author":"hooper","id":"138774","dateCreated":"1603328030","dateModified":"1603328030"},{"type":"inline","comment":"I would prefer \":\" instead of \": \", or at least \" : \".","replyTo":null,"isNewFile":"1","line":"638","lineLength":"0","path":"hgext\/fix.py","diffId":"23265","author":"hooper","id":"138773","dateCreated":"1603328030","dateModified":"1603328030"},{"type":"inline","comment":"Might be more readable to give this expression a name:\n\ndeletion = (firstline == lastline)","replyTo":null,"isNewFile":"1","line":"626","lineLength":"0","path":"hgext\/fix.py","diffId":"23265","author":"hooper","id":"138772","dateCreated":"1603328030","dateModified":"1603328030"},{"type":"inline","comment":"\"Produce a line range for every addition and modification. Conditionally produce ranges for deletions.\"","replyTo":null,"isNewFile":"1","line":"625","lineLength":"0","path":"hgext\/fix.py","diffId":"23265","author":"hooper","id":"138771","dateCreated":"1603328030","dateModified":"1603328030"},{"type":"inline","comment":"The O(lines) initialization of blanks2 is still happening whether or not we use it.","replyTo":"138242","isNewFile":"1","line":"607","lineLength":"0","path":"hgext\/fix.py","diffId":"22764","author":"hooper","id":"138770","dateCreated":"1603328030","dateModified":"1603328030"},{"type":"comment","comment":"The config changes are a big improvement, but I'm still not sure if it's worth supporting. One thing to note is that this feature doesn't help users who have multiple formatters behind a wrapper script configured as a single fixer tool. Configuring it as multiple fixer tools is possible, but not always practical, since it may duplicate some logic between the hg config and something else (sorry to be vague about that).","author":"hooper","id":"138769","dateCreated":"1603328030","dateModified":"1603328030"},{"type":"inline","comment":"this is probably obsolete given the change but I did try to more rigorously define what I'm considering \"whitespace\" here.","replyTo":"138241","isNewFile":"1","line":"49","lineLength":"0","path":"hgext\/fix.py","diffId":"22939","author":"msuozzo","id":"138695","dateCreated":"1603160466","dateModified":"1603160466"},{"type":"comment","comment":"I'm definitely sympathetic to your position.\n\nAs discussed offline, I think an improvement to generality would be to change this config option to relate to deletion diff policies instead and have adjacent blanks be a policy therein.\n\nI'm flexible on naming here. I think \"emitdeletedranges\" is a bit clunky but I can't think of something that fits much better.\n\nPTAL and thanks!","author":"msuozzo","id":"138694","dateCreated":"1603160466","dateModified":"1603160466"},{"type":"update","diffId":"23265","author":"msuozzo","id":"138691","dateCreated":"1603159658","dateModified":"1603159658"},{"type":"inline","comment":"This change introduces the possibility that the appended line range is adjacent to the previous one. I think we should extend the existing line range instead of adding another one. This will avoid exposing that corner case in formatter tools, which will make this extension more reliable in practice. It may also be a performance improvement for some tools that don't consider this case.\n\nPlease include another test case for that, regardless.","replyTo":null,"isNewFile":"1","line":"622","lineLength":"0","path":"hgext\/fix.py","diffId":"22939","author":"hooper","id":"138243","dateCreated":"1602622767","dateModified":"1602622767"},{"type":"inline","comment":"We can additionally make the extra work conditional on the config value.","replyTo":"136885","isNewFile":"1","line":"607","lineLength":"0","path":"hgext\/fix.py","diffId":"22764","author":"hooper","id":"138242","dateCreated":"1602622767","dateModified":"1602622767"},{"type":"inline","comment":"I would explain this more fully by framing it, roughly, as three points:\n1. There is a config that will expand *all* changed line ranges to include adjacent blank lines.\n2. This is useful because it inhibits the previously described omission of deleted line ranges, allowing code formatters to fix whitespace surrounding deletions.\n3. The subtleties of how we define \"adjacent\" and \"blank line\".","replyTo":null,"isNewFile":"1","line":"49","lineLength":"0","path":"hgext\/fix.py","diffId":"22939","author":"hooper","id":"138241","dateCreated":"1602622767","dateModified":"1602622767"},{"type":"comment","comment":"Consider this C++ example:\n\n```\n#include <foo>\n\n#include \"foo.h\"\n```\n\nDeleting the blank line would ideally lead clang-format to add the blank line back. Implementing this kind of behavior on the basis of adjacent blank lines will never provide a complete solution.\n\nNow consider this example:\n\n```\nvoid foo() {\n  int y;\n  if (true) { \n                 int x;\n  } \n}\n```\n\nDelete `int y;`, then format the two adjacent lines unconditionally. The indentation of `int x;` will be fixed, even though it has nothing to do with the diff. This behavior counteracts the purpose of the feature in an avoidable way.\n\nI don't think there is any middle ground here, unless it involves language-aware analysis of the diff. I don't think that belongs here. A more robust solution is to communicate deletions in a precise way to the tools. For example, I think clang-format can reasonably accept it as a zero-length range at a byte offset. How to best express this in configuration is an open question, but it would maintain the separation of concerns between version control and language tools.\n\nI think this change is reducing the robustness of the established interface. It provides some utility, but it also over-promises on its ability to handle deletions. It might be more appropriate as a separate extension that wraps the `difflineranges` function.","author":"hooper","id":"138240","dateCreated":"1602622767","dateModified":"1602622767"},{"type":"comment","comment":"@hooper can you please have a look again. Thank you!","author":"pulkit","id":"137503","dateCreated":"1601973454","dateModified":"1601973454"},{"type":"inline","comment":"Yeah I really considered this but ended up sticking with the current implementation since it meant a byte-wise comparison which I thought would be much faster than a slice comparison.\n\nHowever if we're doing the blank-line calculation once at the top of the function, making it whitespace instead is trivial. Done.","replyTo":"136359","isNewFile":"1","line":"620","lineLength":"0","path":"hgext\/fix.py","diffId":"22764","author":"msuozzo","id":"136886","dateCreated":"1601419555","dateModified":"1601419555"},{"type":"inline","comment":"I'd done this because this is passed to mdiff so I'd assumed that mdiff was already paying the price for storing this construct.\n\nAgain, I'd assumed this was more efficient than the alternative but if you're concerned about the cost, I can definitely calculate whitespace-only lines instead.","replyTo":"136357","isNewFile":"1","line":"607","lineLength":"0","path":"hgext\/fix.py","diffId":"22764","author":"msuozzo","id":"136885","dateCreated":"1601419555","dateModified":"1601419555"},{"type":"update","diffId":"22939","author":"msuozzo","id":"136882","dateCreated":"1601419428","dateModified":"1601419428"},{"type":"inline","comment":"Are we really looking for blank lines, or whitespace-only lines? Does it need to be configurable? I'm worried this behavior is overly specific to your use case.","replyTo":null,"isNewFile":"1","line":"620","lineLength":"0","path":"hgext\/fix.py","diffId":"22764","author":"hooper","id":"136359","dateCreated":"1601075379","dateModified":"1601075379"},{"type":"inline","comment":"You might be able to get away with \"printf\" here, and a newline in :linerange. Not sure about portability, but I've been told to use printf instead of echo before.","replyTo":null,"isNewFile":"1","line":"1486","lineLength":"0","path":"tests\/test-fix.t","diffId":"22764","author":"hooper","id":"136358","dateCreated":"1601075379","dateModified":"1601075379"},{"type":"inline","comment":"I don't think anyone has put a lot of effort into profiling this code, but I'm worried this might increase peak memory use by a significant factor. With large files, this can put users at increased risk of memory exhaustion, swapping, etc. Architectural changes to prevent that are out of scope for this change.\n\nComputing a set of indices for blank lines might be more efficient.","replyTo":null,"isNewFile":"1","line":"607","lineLength":"0","path":"hgext\/fix.py","diffId":"22764","author":"hooper","id":"136357","dateCreated":"1601075379","dateModified":"1601075379"},{"type":"comment","comment":"Alright so as discussed, this is now a per-fixer config option which I called \"adjacentblanks\" (not married to it). There's also the new issue of having to plumb the flag down through the necessary layers of abstraction. I figured doing so with a fixer instance would be the least complex way but I'm not sure how idiomatic that is in hg's codebase.","author":"msuozzo","id":"135964","dateCreated":"1600833067","dateModified":"1600833067"},{"type":"update","diffId":"22764","author":"msuozzo","id":"135963","dateCreated":"1600832888","dateModified":"1600832888"},{"type":"comment","comment":"> Your \":deletion\" suggestion is related to the possibility of supporting \"zero-length byte offset ranges\" or \"zero-length line ranges\" in addition to \"line ranges.\" In general, I would recommend avoiding the temptation to complicate the interface between fix.py and formatter tools. Most of the formatters I've had to integrate with did not support \"formatting a deletion\" anyway. There are some important counter examples like clang-format.\n\nTurns out that was my own comment about :deletion. I see this change as a workaround for formatters that don't explicitly support formatting around deleted sections, regardless of whether we ever implement a way to integrate with formatters that do support it.\n\nI oppose enabling this as default behavior. A plausible way this could go wrong is if formatting an unchanged blank line also implicitly formats an unchanged block of code on the other side. I don't think we can assume that tools will never do this. I do think it would be surprising in a bad way for users, even if we technically don't make any guarantees about the minimal-ness of the diffs used to determine incremental formatting. Not formatting deletions also sucks, but it's less destructive.","author":"hooper","id":"135906","dateCreated":"1600816365","dateModified":"1600816365"},{"type":"comment","comment":"I'm not sure how general the \"blank lines\" heuristic actually is. I think this should be an opt-in feature based on a per-formatter config variable. You can start with an entry in \"FIXER_ATTRS\" and a check around line 685. Whatever we end up with, it needs to be documented in the module docstring (which is the source for hg help -e fix)\n\nI don't have a list of examples handy, but I wouldn't be surprised if this produces bad results in relatively common cases. This tends to be subjective, but we don't want to ship a foot gun :)\n\nYour \":deletion\" suggestion is related to the possibility of supporting \"zero-length byte offset ranges\" or \"zero-length line ranges\" in addition to \"line ranges.\" In general, I would recommend avoiding the temptation to complicate the interface between fix.py and formatter tools. Most of the formatters I've had to integrate with did not support \"formatting a deletion\" anyway. There are some important counter examples like clang-format.","author":"hooper","id":"135887","dateCreated":"1600793545","dateModified":"1600793545"},{"type":"update","diffId":"22738","author":"msuozzo","id":"135740","dateCreated":"1600457474","dateModified":"1600457474"}],"dateCreated":"1600457474","dateModified":"1610572876","status":"Needs Review"},{"id":"9603","callsign":"HG","title":"branchmap: refactor revbranchmap and use it as topicmap [PoC]","author":"joerg.sonnenberger","summary":"","testPlan":"","lineCount":"201","dependsOn":[],"reviewers":[],"ccs":["pulkit","mercurial-patches"],"actions":[{"type":"update","diffId":"24819","author":"joerg.sonnenberger","id":"147387","dateCreated":"1610572212","dateModified":"1610572212"},{"type":"inline","comment":"Yes, but it is a breaking change for topic.","replyTo":"145194","isNewFile":"0","line":"599","lineLength":"0","path":"mercurial\/changelog.py","diffId":"24342","author":"joerg.sonnenberger","id":"145265","dateCreated":"1608322786","dateModified":"1608322786"},{"type":"inline","comment":"As mentioned in the review for the parent, doing a lookup here is expensive and should be avoided. The extra=None case is essentially only used for nullrev. The function name is not terribly good, `parsechangeset` or so would make a lot more sense in the generalized cache.","replyTo":"145196","isNewFile":"1","line":"599","lineLength":"0","path":"mercurial\/branchmap.py","diffId":"24342","author":"joerg.sonnenberger","id":"145264","dateCreated":"1608322786","dateModified":"1608322786"},{"type":"inline","comment":"Right, the primary goal of this PoC is to outline what changes are necessary and what the impact is for supporting more than just the branch mapping. It doesn't make sense as is since it is provided for the benefit out of currently out-of-tree target. So the goal is to get a consensus on whether the cache is useful enough for the topic extension and if it is, split this patch into smaller pieces, figure out a few details in the method naming (e.g. `branchinfo` is tight to the current functionality) in core and how to integrate the rest backwards compatible in the topic extension.","replyTo":"145192","isNewFile":"1","line":"547","lineLength":"0","path":"mercurial\/branchmap.py","diffId":"24342","author":"joerg.sonnenberger","id":"145263","dateCreated":"1608322786","dateModified":"1608322786"},{"type":"inline","comment":"Also, what does a caller passing extra as None is expecting here? It will be nice to not have this an optional argument.\n\nWe can also pass a rev\/node here and do `changelog.changelogrevision` thing in this function.","replyTo":null,"isNewFile":"1","line":"599","lineLength":"0","path":"mercurial\/branchmap.py","diffId":"24342","author":"pulkit","id":"145196","dateCreated":"1608320801","dateModified":"1608320801"},{"type":"comment","comment":">>! In D9603#145191, @pulkit wrote:\n> I like where this is headed. Thank you for doing this work. I can see this patch can be split into at least 3 different patches which will help speed up review.\n\n... of course when it's not a POC anymore.","author":"pulkit","id":"145195","dateCreated":"1608320801","dateModified":"1608320801"},{"type":"inline","comment":"This and related changes should be a separate patch.","replyTo":null,"isNewFile":"0","line":"599","lineLength":"0","path":"mercurial\/changelog.py","diffId":"24342","author":"pulkit","id":"145194","dateCreated":"1608320628","dateModified":"1608320628"},{"type":"inline","comment":"Probably we can have an interface for generic name-cache.","replyTo":null,"isNewFile":"1","line":"782","lineLength":"0","path":"mercurial\/branchmap.py","diffId":"24342","author":"pulkit","id":"145193","dateCreated":"1608320628","dateModified":"1608320628"},{"type":"inline","comment":"This movement of variables can be a separate patch and will be easy one to queue making this patch a bit lighter to review.","replyTo":null,"isNewFile":"1","line":"547","lineLength":"0","path":"mercurial\/branchmap.py","diffId":"24342","author":"pulkit","id":"145192","dateCreated":"1608320628","dateModified":"1608320628"},{"type":"comment","comment":"I like where this is headed. Thank you for doing this work. I can see this patch can be split into at least 3 different patches which will help speed up review.","author":"pulkit","id":"145191","dateCreated":"1608320628","dateModified":"1608320628"},{"type":"update","diffId":"24342","author":"joerg.sonnenberger","id":"144920","dateCreated":"1608212506","dateModified":"1608212506"},{"type":"comment","comment":"The proof of concept part is primarily that we can get the benefit with minimal refactoring of the existing rbc implementation. The actual use is a bit more complicated as the actual topicmap would be part of an extension and therefore hook up differently. But the interaction is much easier to understand like this, IMO.","author":"joerg.sonnenberger","id":"144900","dateCreated":"1608206805","dateModified":"1608206805"},{"type":"comment","comment":"While it's still POC, having some commit message on how we are tackling the problem will be helpful.","author":"pulkit","id":"144832","dateCreated":"1608203029","dateModified":"1608203029"},{"type":"update","diffId":"24309","author":"joerg.sonnenberger","id":"144731","dateCreated":"1608129915","dateModified":"1608129915"},{"type":"update","diffId":"24272","author":"joerg.sonnenberger","id":"144527","dateCreated":"1607981914","dateModified":"1607981914"}],"dateCreated":"1607981914","dateModified":"1610572212","status":"Needs Review"},{"id":"9750","callsign":"HG","title":"node: introduce nodeconstants class","author":"joerg.sonnenberger","summary":"In preparing for moving from SHA1 hashes to a modern hash function,\nplace nullid and other constant magic vules in a class. Provide the\nactive set of constants in the repository and push it down. Provide\nnullid directly in strategic places like the repository as it is\naccessed very often. This changeset introduces the API change, but not\nthe mechanical replacement of the node.py attributes itself.","testPlan":"","lineCount":"299","dependsOn":[],"reviewers":["indygreg","durin42"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":"I'm aiming more for \"only one hash size in the repository\" and the magic constants staying the same independent of the hash function. The hash itself is planned to be tagged, i.e. 248bit for the hash function and the trailing byte as type tag. The SHA1 replacement would use \"01\" and in principle allow for existing SHA1 nodes to embedded directly into the larger 256bit space as type \"00\".","author":"joerg.sonnenberger","id":"147376","dateCreated":"1610567965","dateModified":"1610567965"},{"type":"comment","comment":"So, I'm still not sold on the \"only one hash function in a repo, ever\" constraint of the design this seems to imply. Is there a plan page or anything or is this all in your head?","author":"durin42","id":"147375","dateCreated":"1610567279","dateModified":"1610567279"},{"type":"comment","comment":"This is the API changing part of D9465 without all the followup changes.","author":"joerg.sonnenberger","id":"147242","dateCreated":"1610553418","dateModified":"1610553418"},{"type":"update","diffId":"24786","author":"joerg.sonnenberger","id":"147233","dateCreated":"1610553333","dateModified":"1610553333"}],"dateCreated":"1610553333","dateModified":"1610567965","status":"Needs Review"},{"id":"9465","callsign":"HG","title":"[POC] node: replace nullid and friends with nodeconstants class","author":"joerg.sonnenberger","summary":"The introduction of 256bit hashes require changes to nullid and other\nconstant magic values. Start pushing them down from repository and\nrevlog where sensible.","testPlan":"","lineCount":"2001","dependsOn":[],"reviewers":["indygreg","durin42","martinvonz"],"ccs":["Kwan","mercurial-patches"],"actions":[{"type":"update","diffId":"24306","author":"joerg.sonnenberger","id":"144721","dateCreated":"1608124365","dateModified":"1608124365"},{"type":"update","diffId":"23876","author":"joerg.sonnenberger","id":"142304","dateCreated":"1606735432","dateModified":"1606735432"}],"dateCreated":"1606735432","dateModified":"1610553419","status":"Needs Review"},{"id":"9472","callsign":"HG","title":"testing phabricator encoding","author":"martinvonz","summary":"","testPlan":"","lineCount":"16","dependsOn":[],"reviewers":[],"ccs":["mharbison72","Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":">>! In D9472#143491, @martinvonz wrote:\n>>>! In D9472#143442, @Alphare wrote:\n>> I'm honored to be the mojibake test. ;)\n> \n> :)\n> \n> @mharbison72: I'm not doing anything more with this test. Are you or should I drop this patch? I'll at least mark it \"Plan Changes\" for now.\n\nSorry, I missed this in the tsunami of emails.  I won't have time to look before the freeze in all likelihood, but maybe then?  I wish there was a way to add it to a TODO list so I don't lose it again.","author":"mharbison72","id":"147117","dateCreated":"1610512382","dateModified":"1610512382"},{"type":"comment","comment":">>! In D9472#143442, @Alphare wrote:\n> I'm honored to be the mojibake test. ;)\n\n:)\n\n@mharbison72: I'm not doing anything more with this test. Are you or should I drop this patch? I'll at least mark it \"Plan Changes\" for now.","author":"martinvonz","id":"143492","dateCreated":"1607361839","dateModified":"1607361839"},{"type":"plan-changes","author":"martinvonz","id":"143490","dateCreated":"1607361839","dateModified":"1607361839"},{"type":"comment","comment":"I'm honored to be the mojibake test. ;)","author":"Alphare","id":"143442","dateCreated":"1607336033","dateModified":"1607336033"},{"type":"update","diffId":"23896","author":"martinvonz","id":"142424","dateCreated":"1606808064","dateModified":"1606808064"}],"dateCreated":"1606808064","dateModified":"1610512382","status":"Changes Planned"},{"id":"9587","callsign":"HG","title":"copies: reinstall initial empty files for chained copied","author":"marmoute","summary":"This effectively back out changeset deeb215be337. Changeset deeb215be33 does not\nreally include a justification for its change and make mes uncomfortable. I have\nbeen thinking about it and they are two options:\n\n- either having empty\/full files does not make a difference, and deeb215be337 is\n  a gratuitous changes.\n\n- either having empty\/full files do make a difference and deeb215be33 silently\n  change the test coverage. In such situation if we want the \"not empty\" case to\n  be tested, we should add new cases to cover them\n\nIn practice, we know that the \"file content did not change, but merge still need\nto create a new filenode\" case exists (for example if merging result in similar\ncontent but both parent of the file need to be recorded), and that such case are\neasy to miss\/mess-up in the tests. Having all the file using the same (empty)\ncontent was done on purpose to increase the coverage of such corner case.\n\nAs a result I am reinstalling the previous test situation. If we want to\nincrease the coverage of some case involving content-merge in\ntest-copies-chain-merge.t, we should add a new, dedicated, cases. For the\ncurrent work, it is much more likely to have the corner case broken with the\ncommon case working than the corner case working and the common case broken (cf\nthe next paragraph). So testing the corner case is more important. I also\nsuspect that the common case (merge changing the content) is already covered in\n`test-copies-chain-merge.t` or elsewhere but I did not had time to investigate\nthis in details. I am planning to do a extensive pass on the copy tracing\ntesting to make sure all case we gathered along the way are properly documented\nand tested (I am keeping a list). However they are a lot of things to do\nregarding copy tracing and my bandwidth is limited. I am currently focussing on\ntesting and fixing more important (and currently known to be broken) cases.\n\nDoing so has a large impact on the output of the \"copy info in changeset extra\" variant\nadded in 5e72827dae1e (2 changesets after deeb215be33). It seems to highlight\nvarious breakage when merge without content change are involved, this is a good\nexample of why we want to explicitly test theses cases. Because the different\n-do- matters a lot.\n\nFixing the \"copy info in changeset extra\" is not a priority here. because (1)\nthis changeset does not break anything, it only highlight that they were always\nbroken. (2) the only people using \"copy info in changeset extra\" do not have\nmerge.","testPlan":"","lineCount":"163","dependsOn":[],"reviewers":["martinvonz","Alphare","durin42"],"ccs":["pulkit","durin42","mharbison72","Alphare","martinvonz","mercurial-patches"],"actions":[{"type":"comment","comment":"I guess I don't really understand the position of \"we should back this out\" particularly. Given that it's a test-only change, could we just roll-forward with the new test discussed (that is, a variant of this test with the content the same for all the files)?\n\nAIUI that's the desired end state: a version of this test with contents-same and contents-different files, and the empty files is merely a path to having the contents-same variant. Right? I'd rather not bikeshed about the particular path function to get there, but I'm also not really interested in landing _this specific patch_ because it doesn't improve things - it's just picking the \"files all match\" variant rather than the \"files differ\" variant, but in a way that (I think?) most of us agree is worse (empty files).\n\nSo please either update this patch to introduce a non-empty matching-file version of the test, or let's drop it for now.","author":"durin42","id":"146748","dateCreated":"1610393151","dateModified":"1610393151"},{"type":"reject","author":"durin42","id":"146747","dateCreated":"1610393151","dateModified":"1610393151"},{"type":"comment","comment":">>! In D9587#146006, @pulkit wrote:\n> I had a meeting earlier with @marmoute today and we discussed this. After my discussion and reviewing this patch,  I understood:\n> \n> 1) the motive is to test merging files that have same file content on both sides. So instead of empty files, we probably can have a version of this patch that writes out the same content.\n\nWe can probably have a version of these tests using some explicite content that is indentical on purpose. That will probably requires to adjustement during some merge to make sure we keep the same content 2 content situation. I can follow up with such patch if you want. I would rather keep this one a backout of the on regressing the coverage to avoid mixing different changes. \n\n> 2) Having the same content is breaking tests for `changeset` case. Refer changes around line-354 on both sides.\n> \n> The 2) part makes me think that we should have tests for merging files with the same content. I don't have a strong opinion on how that should be done[1]. @durin42 @mharbison72 thoughts on that?\n> \n> @marmoute @martinvonz correct me if I got something wrong.\n\nI think you got things right.\n\n> \n> [1]: IIRC, I pushed Martin's original patch which added content to files and though Pierre-Yves later commented against it, I didn't understand the hidden benefit that empty files were bringing i.e. merging files with the same content\n\n","author":"marmoute","id":"146155","dateCreated":"1609958557","dateModified":"1609958557"},{"type":"comment","comment":"I had a meeting earlier with @marmoute today and we discussed this. After my discussion and reviewing this patch,  I understood:\n\n1) the motive is to test merging files that have same file content on both sides. So instead of empty files, we probably can have a version of this patch that writes out the same content.\n2) Having the same content is breaking tests for `changeset` case. Refer changes around line-354 on both sides.\n\nThe 2) part makes me think that we should have tests for merging files with the same content. I don't have a strong opinion on how that should be done[1]. @durin42 @mharbison72 thoughts on that?\n\n@marmoute @martinvonz correct me if I got something wrong.\n\n[1]: IIRC, I pushed Martin's original patch which added content to files and though Pierre-Yves later commented against it, I didn't understand the hidden benefit that empty files were bringing i.e. merging files with the same content","author":"pulkit","id":"146007","dateCreated":"1609840087","dateModified":"1609840087"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145963","dateCreated":"1609835899","dateModified":"1609835899"},{"type":"update","diffId":"24573","author":"baymax","id":"145962","dateCreated":"1609835899","dateModified":"1609835899"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145335","dateCreated":"1608536602","dateModified":"1608536602"},{"type":"update","diffId":"24447","author":"baymax","id":"145333","dateCreated":"1608536602","dateModified":"1608536602"},{"type":"comment","comment":">>! In D9587#145182, @martinvonz wrote:\n>>>! In D9587#145179, @Alphare wrote:\n>> It looks like @marmoute has added additional justification for the change. To me, this looks like a decent strategy: prioritize the cases you know to fail, and then slowly go over the rest.\n>> There are clearly corner-cases that we're hitting when using empty files, they're worth testing, as long as the tests for non-empty files come along in a future patch to not lose coverage one way or the other. \n>> I have good insider information that the future patches will come in time, hehe.\n> \n> Can we at least move it out of this series?\n\nThis changeset is part of this series because I am adding more test down the line. And I want to restore the intended test coverage of `test-copies-chain-merge.t` before doing so, so that the new test have the right coverage too.\n\n> And please do it thoroughly and thoughtfully across the entire test suite: go through the test suite and see which tests would work just as well with empty files and update all of them, and of course add duplicate versions with non-empty tests where it might matter (as it does for copy tracing without data in the filelog).\n\nAs explained in this patch, I am planning for a more thoughtful review and consolidation of the test coverage of copy tracing. However bandwidth is limited and I currently focus on covering and fixing some specific cases. As explained in the first part of this reply, I am backing out a regression in test coverage as part of this focus.","author":"marmoute","id":"145313","dateCreated":"1608401363","dateModified":"1608401363"},{"type":"comment","comment":">>! In D9587#145179, @Alphare wrote:\n> It looks like @marmoute has added additional justification for the change. To me, this looks like a decent strategy: prioritize the cases you know to fail, and then slowly go over the rest.\n> There are clearly corner-cases that we're hitting when using empty files, they're worth testing, as long as the tests for non-empty files come along in a future patch to not lose coverage one way or the other. \n> I have good insider information that the future patches will come in time, hehe.\n\nCan we at least move it out of this series? And please do it thoroughly and thoughtfully across the entire test suite: go through the test suite and see which tests would work just as well with empty files and update all of them, and of course add duplicate versions with non-empty tests where it might matter (as it does for copy tracing without data in the filelog).","author":"martinvonz","id":"145182","dateCreated":"1608315976","dateModified":"1608315976"},{"type":"reject","author":"martinvonz","id":"145181","dateCreated":"1608315976","dateModified":"1608315976"},{"type":"comment","comment":"It looks like @marmoute has added additional justification for the change. To me, this looks like a decent strategy: prioritize the cases you know to fail, and then slowly go over the rest.\nThere are clearly corner-cases that we're hitting when using empty files, they're worth testing, as long as the tests for non-empty files come along in a future patch to not lose coverage one way or the other. \nI have good insider information that the future patches will come in time, hehe.","author":"Alphare","id":"145179","dateCreated":"1608311166","dateModified":"1608311166"},{"type":"accept","author":"Alphare","id":"145178","dateCreated":"1608311166","dateModified":"1608311166"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145091","dateCreated":"1608298834","dateModified":"1608298834"},{"type":"update","diffId":"24386","author":"baymax","id":"145090","dateCreated":"1608298834","dateModified":"1608298834"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"144998","dateCreated":"1608238403","dateModified":"1608238403"},{"type":"update","diffId":"24364","author":"baymax","id":"144995","dateCreated":"1608238403","dateModified":"1608238403"},{"type":"comment","comment":"I don't see how this improves testing. I won't queue it and I won't give it an accept stamp. Other reviewers can of course disagree with me.","author":"martinvonz","id":"144620","dateCreated":"1608050236","dateModified":"1608050236"},{"type":"reject","author":"martinvonz","id":"144619","dateCreated":"1608050236","dateModified":"1608050236"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"144431","dateCreated":"1607955342","dateModified":"1607955342"},{"type":"update","diffId":"24251","author":"baymax","id":"144430","dateCreated":"1607955342","dateModified":"1607955342"},{"type":"update","diffId":"24226","author":"marmoute","id":"144335","dateCreated":"1607944667","dateModified":"1607944667"}],"dateCreated":"1607944667","dateModified":"1610393151","status":"Needs Revision"},{"id":"9656","callsign":"HG","title":"copies-rust: use imrs::OrdSet instead of imrs::HashSet","author":"marmoute","summary":"This yield small speedup all over the board, and a large one for our slower\ncases:\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   2.034596 s,   1.465264 s,  -0.569332 s, \u00d7 0.7202,    15 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,   0.694030 s,   0.690376 s,  -0.003654 s, \u00d7 0.9947,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   4.407723 s,   4.011322 s,  -0.396401 s, \u00d7 0.9101,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs,   0.574355 s,   0.573541 s,  -0.000814 s, \u00d7 0.9986,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   4.457827 s,   3.981133 s,  -0.476694 s, \u00d7 0.8931,    10 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.351696 s,   3.996647 s,  -0.355049 s, \u00d7 0.9184,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  80.828689 s,  50.244975 s, -30.583714 s, \u00d7 0.6216,   219 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  34.094064 s,  20.030023 s, -14.064041 s, \u00d7 0.5875,    52 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  27.435529 s,  24.490825 s,  -2.944704 s, \u00d7 0.8927,    53 \u00b5s\/rev\n\nWe also got significantly faster than the implementation using is_ancestors\nexcept for one of our reference case:\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   5.138169 s,   4.011322 s,  -1.126847 s, \u00d7 0.7807,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   5.127809 s,   3.981133 s,  -1.146676 s, \u00d7 0.7764,    10 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.971136 s,   3.996647 s,  -0.974489 s, \u00d7 0.8040,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.741678 s,   1.520607 s,  -0.221071 s, \u00d7 0.8731,     7 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  37.179470 s,  24.490825 s, -12.688645 s, \u00d7 0.6587,    53 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  40.314822 s,  50.244975 s,  +9.930153 s, \u00d7 1.2463,   219 \u00b5s\/rev\n\n\nBelow are three different benchmark comparing this changeset to:\n* the previous one,\n* the implementation based on `is_anscestors`,\n* the filelog copy tracing.\n\n\n### Compared to the previous ones\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmercurial       x_revs_x_added_0_copies               ad6b123de1c7 39cfcef4f463 :      1 revs,   0.000043 s,   0.000041 s,  -0.000002 s, \u00d7 0.9535,    41 \u00b5s\/rev\nmercurial       x_revs_x_added_x_copies               2b1c78674230 0c1d10351869 :      6 revs,   0.000114 s,   0.000116 s,  +0.000002 s, \u00d7 1.0175,    19 \u00b5s\/rev\nmercurial       x000_revs_x000_added_x_copies         81f8ff2a9bf2 dd3267698d84 :   1032 revs,   0.004899 s,   0.004933 s,  +0.000034 s, \u00d7 1.0069,     4 \u00b5s\/rev\npypy            x_revs_x_added_0_copies               aed021ee8ae8 099ed31b181b :      9 revs,   0.000196 s,   0.000193 s,  -0.000003 s, \u00d7 0.9847,    21 \u00b5s\/rev\npypy            x_revs_x000_added_0_copies            4aa4e1f8e19a 359343b9ac0e :      1 revs,   0.000049 s,   0.000048 s,  -0.000001 s, \u00d7 0.9796,    48 \u00b5s\/rev\npypy            x_revs_x_added_x_copies               ac52eb7bbbb0 72e022663155 :      7 revs,   0.000117 s,   0.000114 s,  -0.000003 s, \u00d7 0.9744,    16 \u00b5s\/rev\npypy            x_revs_x00_added_x_copies             c3b14617fbd7 ace7255d9a26 :      1 revs,   0.6f1f4a s,   0.000319 s,  -0.000003 s, \u00d7 0.9907,   319 \u00b5s\/rev\npypy            x_revs_x000_added_x000_copies         df6f7a526b60 a83dc6a2d56f :      6 revs,   0.011856 s,   0.012025 s,  +0.000169 s, \u00d7 1.0143,  2004 \u00b5s\/rev\npypy            x000_revs_xx00_added_0_copies         89a76aede314 2f22446ff07e :   4785 revs,   0.050992 s,   0.050525 s,  -0.000467 s, \u00d7 0.9908,    10 \u00b5s\/rev\npypy            x000_revs_x000_added_x_copies         8a3b5bfd266e 2c68e87c3efe :   6780 revs,   0.087444 s,   0.085713 s,  -0.001731 s, \u00d7 0.9802,    12 \u00b5s\/rev\npypy            x000_revs_x000_added_x000_copies      89a76aede314 7b3dda341c84 :   5441 revs,   0.062487 s,   0.061825 s,  -0.000662 s, \u00d7 0.9894,    11 \u00b5s\/rev\npypy            x0000_revs_x_added_0_copies           d1defd0dc478 c9cb1334cc78 :  43645 revs,   0.634909 s,   0.543998 s,  -0.090911 s, \u00d7 0.8568,    12 \u00b5s\/rev\npypy            x0000_revs_xx000_added_0_copies       bf2c629d0071 4ffed77c095c :      2 revs,   0.013360 s,   0.013455 s,  +0.000095 s, \u00d7 1.0071,  6727 \u00b5s\/rev\npypy            x0000_revs_xx000_added_x000_copies    08ea3258278e d9fa043f30c0 :  11316 revs,   0.120775 s,   0.117479 s,  -0.003296 s, \u00d7 0.9727,    10 \u00b5s\/rev\nnetbeans        x_revs_x_added_0_copies               fb0955ffcbcd a01e9239f9e7 :      2 revs,   0.000085 s,   0.000084 s,  -0.000001 s, \u00d7 0.9882,    42 \u00b5s\/rev\nnetbeans        x_revs_x000_added_0_copies            6f360122949f 20eb231cc7d0 :      2 revs,   0.000108 s,   0.000111 s,  +0.000003 s, \u00d7 1.0278,    55 \u00b5s\/rev\nnetbeans        x_revs_x_added_x_copies               1ada3faf6fb6 5a39d12eecf4 :      3 revs,   0.000176 s,   0.000175 s,  -0.000001 s, \u00d7 0.9943,    58 \u00b5s\/rev\nnetbeans        x_revs_x00_added_x_copies             35be93ba1e2c 9eec5e90c05f :      9 revs,   0.000747 s,   0.000732 s,  -0.000015 s, \u00d7 0.9799,    81 \u00b5s\/rev\nnetbeans        x000_revs_xx00_added_0_copies         eac3045b4fdd 51d4ae7f1290 :   1421 revs,   0.010128 s,   0.010062 s,  -0.000066 s, \u00d7 0.9935,     7 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x_copies         e2063d266acd 6081d72689dc :   1533 revs,   0.015899 s,   0.015659 s,  -0.000240 s, \u00d7 0.9849,    10 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x000_copies      ff453e9fee32 411350406ec2 :   5750 revs,   0.062215 s,   0.062744 s,  +0.000529 s, \u00d7 1.0085,    10 \u00b5s\/rev\nnetbeans        x0000_revs_xx000_added_x000_copies    588c2d1ced70 1aad62e59ddd :  66949 revs,   0.521004 s,   0.499449 s,  -0.021555 s, \u00d7 0.9586,     7 \u00b5s\/rev\nmozilla-central x_revs_x_added_0_copies               3697f962bb7b 7015fcdd43a2 :      2 revs,   0.000090 s,   0.000088 s,  -0.000002 s, \u00d7 0.9778,    44 \u00b5s\/rev\nmozilla-central x_revs_x000_added_0_copies            dd390860c6c9 40d0c5bed75d :      8 revs,   0.000264 s,   0.000266 s,  +0.000002 s, \u00d7 1.0076,    33 \u00b5s\/rev\nmozilla-central x_revs_x_added_x_copies               8d198483ae3b 14207ffc2b2f :      9 revs,   0.000186 s,   0.000182 s,  -0.000004 s, \u00d7 0.9785,    20 \u00b5s\/rev\nmozilla-central x_revs_x00_added_x_copies             98cbc58cc6bc 446a150332c3 :      7 revs,   0.000660 s,   0.000656 s,  -0.000004 s, \u00d7 0.9939,    93 \u00b5s\/rev\nmozilla-central x_revs_x000_added_x000_copies         3c684b4b8f68 0a5e72d1b479 :      3 revs,   0.003542 s,   0.003389 s,  -0.000153 s, \u00d7 0.9568,  1129 \u00b5s\/rev\nmozilla-central x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.071574 s,   0.075882 s,  +0.004308 s, \u00d7 1.0602, 12647 \u00b5s\/rev\nmozilla-central x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006498 s,   0.006479 s,  -0.000019 s, \u00d7 0.9971,     4 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005206 s,   0.004889 s,  -0.000317 s, \u00d7 0.9391,   119 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x000_copies      7c97034feb78 4407bd0c6330 :   7839 revs,   0.065535 s,   0.064394 s,  -0.001141 s, \u00d7 0.9826,     8 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027139 s,   0.026815 s,  -0.000324 s, \u00d7 0.9881,    43 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_x000_copies    f78c615a656c 96a38b690156 :  30263 revs,   0.201924 s,   0.cc85eb s,  +0.000940 s, \u00d7 1.0047,     6 \u00b5s\/rev\nmozilla-central x00000_revs_x0000_added_x0000_copies  6832ae71433c 4c222a1d9a00 : 153721 revs,   1.257201 s,   1.219445 s,  -0.037756 s, \u00d7 0.9700,     7 \u00b5s\/rev\nmozilla-central x00000_revs_x00000_added_x000_copies  76caed42cf7c 1daa622bbe42 : 204976 revs,   1.663045 s,   1.613857 s,  -0.049188 s, \u00d7 0.9704,     7 \u00b5s\/rev\nmozilla-try     x_revs_x_added_0_copies               aaf6dde0deb8 9790f499805a :      2 revs,   0.000866 s,   0.000873 s,  +0.000007 s, \u00d7 1.0081,   436 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_0_copies            d8d0222927b4 5bb8ce8c7450 :      2 revs,   0.000883 s,   0.000885 s,  +0.000002 s, \u00d7 1.0023,   442 \u00b5s\/rev\nmozilla-try     x_revs_x_added_x_copies               092fcca11bdb 936255a0384a :      4 revs,   0.000163 s,   0.000161 s,  -0.000002 s, \u00d7 0.9877,    40 \u00b5s\/rev\nmozilla-try     x_revs_x00_added_x_copies             b53d2fadbdb5 017afae788ec :      2 revs,   0.001139 s,   0.001138 s,  -0.000001 s, \u00d7 0.9991,   569 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_x000_copies         20408ad61ce5 6f0ee96e21ad :      1 revs,   0.032753 s,   0.033399 s,  +0.000646 s, \u00d7 1.0197, 33399 \u00b5s\/rev\nmozilla-try     x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.073266 s,   0.075445 s,  +0.002179 s, \u00d7 1.0297, 12574 \u00b5s\/rev\nmozilla-try     x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006567 s,   0.006456 s,  -0.000111 s, \u00d7 0.9831,     4 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005427 s,   0.005462 s,  +0.000035 s, \u00d7 1.0064,   133 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x000_copies      1346fd0130e4 4c65cbdabc1f :   6657 revs,   0.064058 s,   0.064117 s,  +0.000059 s, \u00d7 1.0009,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_0_copies           63519bfd42ee a36a2a865d92 :  40314 revs,   0.303320 s,   0.297563 s,  -0.005757 s, \u00d7 0.9810,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_x_copies           9fe69ff0762d bcabf2a78927 :  38690 revs,   0.288456 s,   0.282463 s,  -0.005993 s, \u00d7 0.9792,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x_copies       156f6e2674f2 4d0f2c178e66 :   8598 revs,   0.085925 s,   0.084038 s,  -0.001887 s, \u00d7 0.9780,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027302 s,   0.027306 s,  +0.000004 s, \u00d7 1.0001,    44 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   2.034596 s,   1.465264 s,  -0.569332 s, \u00d7 0.7202,    15 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,   0.694030 s,   0.690376 s,  -0.003654 s, \u00d7 0.9947,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   4.407723 s,   4.011322 s,  -0.396401 s, \u00d7 0.9101,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs,   0.574355 s,   0.573541 s,  -0.000814 s, \u00d7 0.9986,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   4.457827 s,   3.981133 s,  -0.476694 s, \u00d7 0.8931,    10 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.351696 s,   3.996647 s,  -0.355049 s, \u00d7 0.9184,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.570065 s,   1.520607 s,  -0.049458 s, \u00d7 0.9685,     7 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  80.828689 s,  50.244975 s, -30.583714 s, \u00d7 0.6216,   219 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  34.094064 s,  20.030023 s, -14.064041 s, \u00d7 0.5875,    52 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  27.435529 s,  24.490825 s,  -2.944704 s, \u00d7 0.8927,    53 \u00b5s\/rev\n\n### Compared to the implementation using `is_anscestor`\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmercurial       x_revs_x_added_0_copies               ad6b123de1c7 39cfcef4f463 :      1 revs,   0.000042 s,   0.000041 s,  -0.000001 s, \u00d7 0.9762,    41 \u00b5s\/rev\nmercurial       x_revs_x_added_x_copies               2b1c78674230 0c1d10351869 :      6 revs,   0.000110 s,   0.000116 s,  +0.000006 s, \u00d7 1.0545,    19 \u00b5s\/rev\nmercurial       x000_revs_x000_added_x_copies         81f8ff2a9bf2 dd3267698d84 :   1032 revs,   0.004945 s,   0.004933 s,  -0.000012 s, \u00d7 0.9976,     4 \u00b5s\/rev\npypy            x_revs_x_added_0_copies               aed021ee8ae8 099ed31b181b :      9 revs,   0.000192 s,   0.000193 s,  +0.000001 s, \u00d7 1.0052,    21 \u00b5s\/rev\npypy            x_revs_x000_added_0_copies            4aa4e1f8e19a 359343b9ac0e :      1 revs,   0.000049 s,   0.000048 s,  -0.000001 s, \u00d7 0.9796,    48 \u00b5s\/rev\npypy            x_revs_x_added_x_copies               ac52eb7bbbb0 72e022663155 :      7 revs,   0.000112 s,   0.000114 s,  +0.000002 s, \u00d7 1.0179,    16 \u00b5s\/rev\npypy            x_revs_x00_added_x_copies             c3b14617fbd7 ace7255d9a26 :      1 revs,   0.000323 s,   0.000319 s,  -0.000004 s, \u00d7 0.9876,   319 \u00b5s\/rev\npypy            x_revs_x000_added_x000_copies         df6f7a526b60 a83dc6a2d56f :      6 revs,   0.010042 s,   0.012025 s,  +0.001983 s, \u00d7 1.1975,  2004 \u00b5s\/rev\npypy            x000_revs_xx00_added_0_copies         89a76aede314 2f22446ff07e :   4785 revs,   0.049813 s,   0.050525 s,  +0.000712 s, \u00d7 1.0143,    10 \u00b5s\/rev\npypy            x000_revs_x000_added_x_copies         8a3b5bfd266e 2c68e87c3efe :   6780 revs,   0.079937 s,   0.085713 s,  +0.005776 s, \u00d7 1.0723,    12 \u00b5s\/rev\npypy            x000_revs_x000_added_x000_copies      89a76aede314 7b3dda341c84 :   5441 revs,   0.059412 s,   0.061825 s,  +0.002413 s, \u00d7 1.0406,    11 \u00b5s\/rev\npypy            x0000_revs_x_added_0_copies           d1defd0dc478 c9cb1334cc78 :  43645 revs,   0.533769 s,   0.543998 s,  +0.010229 s, \u00d7 1.0192,    12 \u00b5s\/rev\npypy            x0000_revs_xx000_added_0_copies       bf2c629d0071 4ffed77c095c :      2 revs,   0.013147 s,   0.013455 s,  +0.000308 s, \u00d7 1.0234,  6727 \u00b5s\/rev\npypy            x0000_revs_xx000_added_x000_copies    08ea3258278e d9fa043f30c0 :  11316 revs,   0.110680 s,   0.117479 s,  +0.006799 s, \u00d7 1.0614,    10 \u00b5s\/rev\nnetbeans        x_revs_x_added_0_copies               fb0955ffcbcd a01e9239f9e7 :      2 revs,   0.000085 s,   0.000084 s,  -0.000001 s, \u00d7 0.9882,    42 \u00b5s\/rev\nnetbeans        x_revs_x000_added_0_copies            6f360122949f 20eb231cc7d0 :      2 revs,   0.000107 s,   0.000111 s,  +0.000004 s, \u00d7 1.0374,    55 \u00b5s\/rev\nnetbeans        x_revs_x_added_x_copies               1ada3faf6fb6 5a39d12eecf4 :      3 revs,   0.000175 s,   0.000175 s,  +0.000000 s, \u00d7 1.0000,    58 \u00b5s\/rev\nnetbeans        x_revs_x00_added_x_copies             35be93ba1e2c 9eec5e90c05f :      9 revs,   0.000720 s,   0.000732 s,  +0.000012 s, \u00d7 1.0167,    81 \u00b5s\/rev\nnetbeans        x000_revs_xx00_added_0_copies         eac3045b4fdd 51d4ae7f1290 :   1421 revs,   0.010019 s,   0.010062 s,  +0.000043 s, \u00d7 1.0043,     7 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x_copies         e2063d266acd 6081d72689dc :   1533 revs,   0.015602 s,   0.015659 s,  +0.000057 s, \u00d7 1.0037,    10 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x000_copies      ff453e9fee32 411350406ec2 :   5750 revs,   0.058759 s,   0.062744 s,  +0.003985 s, \u00d7 1.0678,    10 \u00b5s\/rev\nnetbeans        x0000_revs_xx000_added_x000_copies    588c2d1ced70 1aad62e59ddd :  66949 revs,   0.491550 s,   0.499449 s,  +0.007899 s, \u00d7 1.0161,     7 \u00b5s\/rev\nmozilla-central x_revs_x_added_0_copies               3697f962bb7b 7015fcdd43a2 :      2 revs,   0.000087 s,   0.000088 s,  +0.000001 s, \u00d7 1.0115,    44 \u00b5s\/rev\nmozilla-central x_revs_x000_added_0_copies            dd390860c6c9 40d0c5bed75d :      8 revs,   0.000268 s,   0.000266 s,  -0.000002 s, \u00d7 0.9925,    33 \u00b5s\/rev\nmozilla-central x_revs_x_added_x_copies               8d198483ae3b 14207ffc2b2f :      9 revs,   0.000181 s,   0.000182 s,  +0.000001 s, \u00d7 1.0055,    20 \u00b5s\/rev\nmozilla-central x_revs_x00_added_x_copies             98cbc58cc6bc 446a150332c3 :      7 revs,   0.000661 s,   0.000656 s,  -0.000005 s, \u00d7 0.9924,    93 \u00b5s\/rev\nmozilla-central x_revs_x000_added_x000_copies         3c684b4b8f68 0a5e72d1b479 :      3 revs,   0.003256 s,   0.003389 s,  +0.000133 s, \u00d7 1.0408,  1129 \u00b5s\/rev\nmozilla-central x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.066749 s,   0.075882 s,  +0.009133 s, \u00d7 1.1368, 12647 \u00b5s\/rev\nmozilla-central x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006462 s,   0.006479 s,  +0.000017 s, \u00d7 1.0026,     4 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.004919 s,   0.004889 s,  -0.000030 s, \u00d7 0.9939,   119 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x000_copies      7c97034feb78 4407bd0c6330 :   7839 revs,   0.062421 s,   0.064394 s,  +0.001973 s, \u00d7 1.0316,     8 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.026633 s,   0.026815 s,  +0.000182 s, \u00d7 1.0068,    43 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_x000_copies    f78c615a656c 96a38b690156 :  30263 revs,   0.197792 s,   0.cc85eb s,  +0.005072 s, \u00d7 1.0256,     6 \u00b5s\/rev\nmozilla-central x00000_revs_x0000_added_x0000_copies  6832ae71433c 4c222a1d9a00 : 153721 revs,   1.259970 s,   1.219445 s,  -0.040525 s, \u00d7 0.9678,     7 \u00b5s\/rev\nmozilla-central x00000_revs_x00000_added_x000_copies  76caed42cf7c 1daa622bbe42 : 204976 revs,   1.689184 s,   1.613857 s,  -0.075327 s, \u00d7 0.9554,     7 \u00b5s\/rev\nmozilla-try     x_revs_x_added_0_copies               aaf6dde0deb8 9790f499805a :      2 revs,   0.000865 s,   0.000873 s,  +0.000008 s, \u00d7 1.0092,   436 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_0_copies            d8d0222927b4 5bb8ce8c7450 :      2 revs,   0.000893 s,   0.000885 s,  -0.000008 s, \u00d7 0.9910,   442 \u00b5s\/rev\nmozilla-try     x_revs_x_added_x_copies               092fcca11bdb 936255a0384a :      4 revs,   0.000172 s,   0.000161 s,  -0.000011 s, \u00d7 0.9360,    40 \u00b5s\/rev\nmozilla-try     x_revs_x00_added_x_copies             b53d2fadbdb5 017afae788ec :      2 revs,   0.001159 s,   0.001138 s,  -0.000021 s, \u00d7 0.9819,   569 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_x000_copies         20408ad61ce5 6f0ee96e21ad :      1 revs,   0.031621 s,   0.033399 s,  +0.001778 s, \u00d7 1.0562, 33399 \u00b5s\/rev\nmozilla-try     x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.068571 s,   0.075445 s,  +0.006874 s, \u00d7 1.1002, 12574 \u00b5s\/rev\nmozilla-try     x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006452 s,   0.006456 s,  +0.000004 s, \u00d7 1.0006,     4 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005443 s,   0.005462 s,  +0.000019 s, \u00d7 1.0035,   133 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x000_copies      1346fd0130e4 4c65cbdabc1f :   6657 revs,   0.063180 s,   0.064117 s,  +0.000937 s, \u00d7 1.0148,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_0_copies           63519bfd42ee a36a2a865d92 :  40314 revs,   0.293564 s,   0.297563 s,  +0.003999 s, \u00d7 1.0136,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_x_copies           9fe69ff0762d bcabf2a78927 :  38690 revs,   0.286595 s,   0.282463 s,  -0.004132 s, \u00d7 0.9856,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x_copies       156f6e2674f2 4d0f2c178e66 :   8598 revs,   0.083256 s,   0.084038 s,  +0.000782 s, \u00d7 1.0094,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027282 s,   0.027306 s,  +0.000024 s, \u00d7 1.0009,    44 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   1.343373 s,   1.465264 s,  +0.121891 s, \u00d7 1.0907,    15 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,   0.665737 s,   0.690376 s,  +0.024639 s, \u00d7 1.0370,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   5.138169 s,   4.011322 s,  -1.126847 s, \u00d7 0.7807,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs,   0.573276 s,   0.573541 s,  +0.000265 s, \u00d7 1.0005,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   5.127809 s,   3.981133 s,  -1.146676 s, \u00d7 0.7764,    10 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.971136 s,   3.996647 s,  -0.974489 s, \u00d7 0.8040,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.741678 s,   1.520607 s,  -0.221071 s, \u00d7 0.8731,     7 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  40.314822 s,  50.244975 s,  +9.930153 s, \u00d7 1.2463,   219 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  20.048029 s,  20.030023 s,  -0.018006 s, \u00d7 0.9991,    52 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  37.179470 s,  24.490825 s, -12.688645 s, \u00d7 0.6587,    53 \u00b5s\/rev\n\n### Compared to the filelog based copy tracing\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmercurial       x_revs_x_added_0_copies               ad6b123de1c7 39cfcef4f463 :      1 revs,  0.000918 s,  0.000041 s,  -0.000877 s, \u00d7 0.044662,    40 \u00b5s\/rev\nmercurial       x_revs_x_added_x_copies               2b1c78674230 0c1d10351869 :      6 revs,  0.001853 s,  0.000116 s,  -0.001737 s, \u00d7 0.062601,    19 \u00b5s\/rev\nmercurial       x000_revs_x000_added_x_copies         81f8ff2a9bf2 dd3267698d84 :   1032 revs,  0.018994 s,  0.004933 s,  -0.014061 s, \u00d7 0.259714,     4 \u00b5s\/rev\npypy            x_revs_x_added_0_copies               aed021ee8ae8 099ed31b181b :      9 revs,  0.001532 s,  0.000193 s,  -0.001339 s, \u00d7 0.125979,    21 \u00b5s\/rev\npypy            x_revs_x000_added_0_copies            4aa4e1f8e19a 359343b9ac0e :      1 revs,  0.210633 s,  0.000048 s,  -0.210585 s, \u00d7 0.000228,    47 \u00b5s\/rev\npypy            x_revs_x_added_x_copies               ac52eb7bbbb0 72e022663155 :      7 revs,  0.017041 s,  0.000114 s,  -0.016927 s, \u00d7 0.006690,    16 \u00b5s\/rev\npypy            x_revs_x00_added_x_copies             c3b14617fbd7 ace7255d9a26 :      1 revs,  0.019474 s,  0.000319 s,  -0.019155 s, \u00d7 0.016381,   318 \u00b5s\/rev\npypy            x_revs_x000_added_x000_copies         df6f7a526b60 a83dc6a2d56f :      6 revs,  0.763136 s,  0.012025 s,  -0.751111 s, \u00d7 0.015757,  2003 \u00b5s\/rev\npypy            x000_revs_xx00_added_0_copies         89a76aede314 2f22446ff07e :   4785 revs,  1.226569 s,  0.050525 s,  -1.176044 s, \u00d7 0.041192,    10 \u00b5s\/rev\npypy            x000_revs_x000_added_x_copies         8a3b5bfd266e 2c68e87c3efe :   6780 revs,  1.314572 s,  0.085713 s,  -1.228859 s, \u00d7 0.065202,    12 \u00b5s\/rev\npypy            x000_revs_x000_added_x000_copies      89a76aede314 7b3dda341c84 :   5441 revs,  1.686022 s,  0.061825 s,  -1.624197 s, \u00d7 0.036669,    11 \u00b5s\/rev\npypy            x0000_revs_x_added_0_copies           d1defd0dc478 c9cb1334cc78 :  43645 revs,  0.001110 s,  0.543998 s,  +0.542888 s, \u00d7 490.0882,    12 \u00b5s\/rev\npypy            x0000_revs_xx000_added_0_copies       bf2c629d0071 4ffed77c095c :      2 revs,  1.106265 s,  0.013455 s,  -1.092810 s, \u00d7 0.012163,  6724 \u00b5s\/rev\npypy            x0000_revs_xx000_added_x000_copies    08ea3258278e d9fa043f30c0 :  11316 revs,  1.377398 s,  0.117479 s,  -1.259919 s, \u00d7 0.085291,    10 \u00b5s\/rev\nnetbeans        x_revs_x_added_0_copies               fb0955ffcbcd a01e9239f9e7 :      2 revs,  0.028579 s,  0.000084 s,  -0.028495 s, \u00d7 0.002939,    41 \u00b5s\/rev\nnetbeans        x_revs_x000_added_0_copies            6f360122949f 20eb231cc7d0 :      2 revs,  0.133644 s,  0.000111 s,  -0.133533 s, \u00d7 0.000831,    55 \u00b5s\/rev\nnetbeans        x_revs_x_added_x_copies               1ada3faf6fb6 5a39d12eecf4 :      3 revs,  0.025988 s,  0.000175 s,  -0.025813 s, \u00d7 0.006734,    58 \u00b5s\/rev\nnetbeans        x_revs_x00_added_x_copies             35be93ba1e2c 9eec5e90c05f :      9 revs,  0.053011 s,  0.000732 s,  -0.052279 s, \u00d7 0.013808,    81 \u00b5s\/rev\nnetbeans        x000_revs_xx00_added_0_copies         eac3045b4fdd 51d4ae7f1290 :   1421 revs,  0.037858 s,  0.010062 s,  -0.027796 s, \u00d7 0.265783,     7 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x_copies         e2063d266acd 6081d72689dc :   1533 revs,  0.200517 s,  0.015659 s,  -0.184858 s, \u00d7 0.078093,    10 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x000_copies      ff453e9fee32 411350406ec2 :   5750 revs,  0.964542 s,  0.062744 s,  -0.901798 s, \u00d7 0.065051,    10 \u00b5s\/rev\nnetbeans        x0000_revs_xx000_added_x000_copies    588c2d1ced70 1aad62e59ddd :  66949 revs,  3.976210 s,  0.499449 s,  -3.476761 s, \u00d7 0.125609,     7 \u00b5s\/rev\nmozilla-central x_revs_x_added_0_copies               3697f962bb7b 7015fcdd43a2 :      2 revs,  0.025172 s,  0.000088 s,  -0.025084 s, \u00d7 0.003496,    43 \u00b5s\/rev\nmozilla-central x_revs_x000_added_0_copies            dd390860c6c9 40d0c5bed75d :      8 revs,  0.145144 s,  0.000266 s,  -0.144878 s, \u00d7 0.001833,    33 \u00b5s\/rev\nmozilla-central x_revs_x_added_x_copies               8d198483ae3b 14207ffc2b2f :      9 revs,  0.026139 s,  0.000182 s,  -0.025957 s, \u00d7 0.006963,    20 \u00b5s\/rev\nmozilla-central x_revs_x00_added_x_copies             98cbc58cc6bc 446a150332c3 :      7 revs,  0.086184 s,  0.000656 s,  -0.085528 s, \u00d7 0.007612,    93 \u00b5s\/rev\nmozilla-central x_revs_x000_added_x000_copies         3c684b4b8f68 0a5e72d1b479 :      3 revs,  0.203187 s,  0.003389 s,  -0.199798 s, \u00d7 0.016679,  1129 \u00b5s\/rev\nmozilla-central x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,  2.255675 s,  0.075882 s,  -2.179793 s, \u00d7 0.033640, 12644 \u00b5s\/rev\nmozilla-central x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,  0.091147 s,  0.006479 s,  -0.084668 s, \u00d7 0.071083,     4 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,  0.767530 s,  0.004889 s,  -0.762641 s, \u00d7 0.006370,   119 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x000_copies      7c97034feb78 4407bd0c6330 :   7839 revs,  1.185330 s,  0.064394 s,  -1.120936 s, \u00d7 0.054326,     8 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,  6.831179 s,  0.026815 s,  -6.804364 s, \u00d7 0.003925,    43 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_x000_copies    f78c615a656c 96a38b690156 :  30263 revs,  3.373551 s,  0.cc85eb s,  -3.170687 s, \u00d7 0.060134,     6 \u00b5s\/rev\nmozilla-central x00000_revs_x0000_added_x0000_copies  6832ae71433c 4c222a1d9a00 : 153721 revs, 16.540604 s,  1.219445 s, -15.321159 s, \u00d7 0.073724,     7 \u00b5s\/rev\nmozilla-central x00000_revs_x00000_added_x000_copies  76caed42cf7c 1daa622bbe42 : 204976 revs, 21.527155 s,  1.613857 s, -19.913298 s, \u00d7 0.074968,     7 \u00b5s\/rev\nmozilla-try     x_revs_x_added_0_copies               aaf6dde0deb8 9790f499805a :      2 revs,  0.084540 s,  0.000873 s,  -0.083667 s, \u00d7 0.010326,   436 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_0_copies            d8d0222927b4 5bb8ce8c7450 :      2 revs,  0.507151 s,  0.000885 s,  -0.506266 s, \u00d7 0.001745,   442 \u00b5s\/rev\nmozilla-try     x_revs_x_added_x_copies               092fcca11bdb 936255a0384a :      4 revs,  0.021748 s,  0.000161 s,  -0.021587 s, \u00d7 0.007403,    40 \u00b5s\/rev\nmozilla-try     x_revs_x00_added_x_copies             b53d2fadbdb5 017afae788ec :      2 revs,  0.236786 s,  0.001138 s,  -0.235648 s, \u00d7 0.004806,   568 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_x000_copies         20408ad61ce5 6f0ee96e21ad :      1 revs,  1.111735 s,  0.033399 s,  -1.078336 s, \u00d7 0.030042, 33365 \u00b5s\/rev\nmozilla-try     x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,  2.228030 s,  0.075445 s,  -2.152585 s, \u00d7 0.033862, 12572 \u00b5s\/rev\nmozilla-try     x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,  0.091289 s,  0.006456 s,  -0.084833 s, \u00d7 0.070720,     4 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,  0.771361 s,  0.005462 s,  -0.765899 s, \u00d7 0.007081,   133 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x000_copies      1346fd0130e4 4c65cbdabc1f :   6657 revs,  1.189483 s,  0.064117 s,  -1.125366 s, \u00d7 0.053903,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_0_copies           63519bfd42ee a36a2a865d92 :  40314 revs,  0.089756 s,  0.297563 s,  +0.207807 s, \u00d7 3.315244,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_x_copies           9fe69ff0762d bcabf2a78927 :  38690 revs,  0.084888 s,  0.282463 s,  +0.197575 s, \u00d7 3.327479,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x_copies       156f6e2674f2 4d0f2c178e66 :   8598 revs,  7.682665 s,  0.084038 s,  -7.598627 s, \u00d7 0.010939,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,  6.894680 s,  0.027306 s,  -6.867374 s, \u00d7 0.003960,    44 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,  7.650907 s,  1.465264 s,  -6.185643 s, \u00d7 0.191515,    15 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,  9.898788 s,  0.690376 s,  -9.208412 s, \u00d7 0.069743,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,  0.092208 s,  4.011322 s,  +3.919114 s, \u00d7 43.50297,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs, 28.130003 s,  0.573541 s, -27.556462 s, \u00d7 0.020389,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,  0.093366 s,  3.981133 s,  +3.887767 s, \u00d7 42.64007,    10 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,  0.229368 s,  3.996647 s,  +3.767279 s, \u00d7 17.42460,    11 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs, 19.624851 s,  1.520607 s, -18.104244 s, \u00d7 0.077484,     7 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs, 22.070126 s, 50.244975 s, +28.174849 s, \u00d7 2.276606,   219 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs, 26.006524 s, 20.030023 s,  -5.976501 s, \u00d7 0.770192,    52 \u00b5s\/rev\nprivate                                                                         : 459513 revs, 18.704612 s, 24.490825 s,  +5.786213 s, \u00d7 1.309347,    53 \u00b5s\/rev","testPlan":"","lineCount":"8","dependsOn":["9655"],"reviewers":["SimonSapin","Alphare"],"ccs":["SimonSapin","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146594","dateCreated":"1610147775","dateModified":"1610147775"},{"type":"update","diffId":"24681","author":"baymax","id":"146593","dateCreated":"1610147775","dateModified":"1610147775"},{"type":"accept","author":"Alphare","id":"146302","dateCreated":"1610115358","dateModified":"1610115358"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145997","dateCreated":"1609837669","dateModified":"1609837669"},{"type":"update","diffId":"24590","author":"baymax","id":"145996","dateCreated":"1609837669","dateModified":"1609837669"},{"type":"comment","comment":"The speedup comes from `OrdMap` using reference counting internally, so `clone()` does not need to allocate. (Mutation after clone does copy-on-writes and allocate, but that\u2019s evidently less frequent.) Background: https:\/\/docs.rs\/im-rc\/15.0.0\/im_rc\/#when-does-cloning-happen","author":"SimonSapin","id":"145776","dateCreated":"1609168511","dateModified":"1609168511"},{"type":"accept","author":"SimonSapin","id":"145775","dateCreated":"1609168511","dateModified":"1609168511"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145649","dateCreated":"1608691608","dateModified":"1608691608"},{"type":"update","diffId":"24506","author":"baymax","id":"145648","dateCreated":"1608691608","dateModified":"1608691608"},{"type":"update","diffId":"24495","author":"marmoute","id":"145622","dateCreated":"1608689558","dateModified":"1608689558"},{"type":"update","diffId":"24480","author":"marmoute","id":"145528","dateCreated":"1608589763","dateModified":"1608589763"}],"dateCreated":"1608589763","dateModified":"1610147775","status":"Needs Review"},{"id":"9655","callsign":"HG","title":"copies-rust: use simpler overwrite when value on both side are identical","author":"marmoute","summary":"If the value are the same, their \"overwritten\" set is the same and we don't need\nto combine them.\n\n\nIt helps our slower cases\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  86.722016 s,  80.828689 s,  -5.893327 s, \u00d7 0.9320,   352 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  35.113727 s,  34.094064 s,  -1.019663 s, \u00d7 0.9710,    89 \u00b5s\/rev\n\nFull comparison with the previous revision below:\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmercurial       x_revs_x_added_0_copies               ad6b123de1c7 39cfcef4f463 :      1 revs,   0.000043 s,   0.000043 s,  +0.000000 s, \u00d7 1.0000,    43 \u00b5s\/rev\nmercurial       x_revs_x_added_x_copies               2b1c78674230 0c1d10351869 :      6 revs,   0.000114 s,   0.000114 s,  +0.000000 s, \u00d7 1.0000,    19 \u00b5s\/rev\nmercurial       x000_revs_x000_added_x_copies         81f8ff2a9bf2 dd3267698d84 :   1032 revs,   0.004899 s,   0.004899 s,  +0.000000 s, \u00d7 1.0000,     4 \u00b5s\/rev\npypy            x_revs_x_added_0_copies               aed021ee8ae8 099ed31b181b :      9 revs,   0.000196 s,   0.000196 s,  +0.000000 s, \u00d7 1.0000,    21 \u00b5s\/rev\npypy            x_revs_x000_added_0_copies            4aa4e1f8e19a 359343b9ac0e :      1 revs,   0.000050 s,   0.000049 s,  -0.000001 s, \u00d7 0.9800,    49 \u00b5s\/rev\npypy            x_revs_x_added_x_copies               ac52eb7bbbb0 72e022663155 :      7 revs,   0.000125 s,   0.000117 s,  -0.000008 s, \u00d7 0.9360,    16 \u00b5s\/rev\npypy            x_revs_x00_added_x_copies             c3b14617fbd7 ace7255d9a26 :      1 revs,   0.000321 s,   0.6f1f4a s,  +0.000001 s, \u00d7 1.0031,   322 \u00b5s\/rev\npypy            x_revs_x000_added_x000_copies         df6f7a526b60 a83dc6a2d56f :      6 revs,   0.011948 s,   0.011856 s,  -0.000092 s, \u00d7 0.9923,  1976 \u00b5s\/rev\npypy            x000_revs_xx00_added_0_copies         89a76aede314 2f22446ff07e :   4785 revs,   0.051267 s,   0.050992 s,  -0.000275 s, \u00d7 0.9946,    10 \u00b5s\/rev\npypy            x000_revs_x000_added_x_copies         8a3b5bfd266e 2c68e87c3efe :   6780 revs,   0.087755 s,   0.087444 s,  -0.000311 s, \u00d7 0.9965,    12 \u00b5s\/rev\npypy            x000_revs_x000_added_x000_copies      89a76aede314 7b3dda341c84 :   5441 revs,   0.061818 s,   0.062487 s,  +0.000669 s, \u00d7 1.0108,    11 \u00b5s\/rev\npypy            x0000_revs_x_added_0_copies           d1defd0dc478 c9cb1334cc78 :  43645 revs,   0.634253 s,   0.634909 s,  +0.000656 s, \u00d7 1.0010,    14 \u00b5s\/rev\npypy            x0000_revs_xx000_added_0_copies       bf2c629d0071 4ffed77c095c :      2 revs,   0.013179 s,   0.013360 s,  +0.000181 s, \u00d7 1.0137,  6680 \u00b5s\/rev\npypy            x0000_revs_xx000_added_x000_copies    08ea3258278e d9fa043f30c0 :  11316 revs,   0.119643 s,   0.120775 s,  +0.001132 s, \u00d7 1.0095,    10 \u00b5s\/rev\nnetbeans        x_revs_x_added_0_copies               fb0955ffcbcd a01e9239f9e7 :      2 revs,   0.000085 s,   0.000085 s,  +0.000000 s, \u00d7 1.0000,    42 \u00b5s\/rev\nnetbeans        x_revs_x000_added_0_copies            6f360122949f 20eb231cc7d0 :      2 revs,   0.000107 s,   0.000108 s,  +0.000001 s, \u00d7 1.0093,    54 \u00b5s\/rev\nnetbeans        x_revs_x_added_x_copies               1ada3faf6fb6 5a39d12eecf4 :      3 revs,   0.000176 s,   0.000176 s,  +0.000000 s, \u00d7 1.0000,    58 \u00b5s\/rev\nnetbeans        x_revs_x00_added_x_copies             35be93ba1e2c 9eec5e90c05f :      9 revs,   0.000743 s,   0.000747 s,  +0.000004 s, \u00d7 1.0054,    83 \u00b5s\/rev\nnetbeans        x000_revs_xx00_added_0_copies         eac3045b4fdd 51d4ae7f1290 :   1421 revs,   0.010246 s,   0.010128 s,  -0.000118 s, \u00d7 0.9885,     7 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x_copies         e2063d266acd 6081d72689dc :   1533 revs,   0.015853 s,   0.015899 s,  +0.000046 s, \u00d7 1.0029,    10 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x000_copies      ff453e9fee32 411350406ec2 :   5750 revs,   0.062971 s,   0.062215 s,  -0.000756 s, \u00d7 0.9880,    10 \u00b5s\/rev\nnetbeans        x0000_revs_xx000_added_x000_copies    588c2d1ced70 1aad62e59ddd :  66949 revs,   0.518337 s,   0.521004 s,  +0.002667 s, \u00d7 1.0051,     7 \u00b5s\/rev\nmozilla-central x_revs_x_added_0_copies               3697f962bb7b 7015fcdd43a2 :      2 revs,   0.000090 s,   0.000090 s,  +0.000000 s, \u00d7 1.0000,    45 \u00b5s\/rev\nmozilla-central x_revs_x000_added_0_copies            dd390860c6c9 40d0c5bed75d :      8 revs,   0.000268 s,   0.000264 s,  -0.000004 s, \u00d7 0.9851,    33 \u00b5s\/rev\nmozilla-central x_revs_x_added_x_copies               8d198483ae3b 14207ffc2b2f :      9 revs,   0.000187 s,   0.000186 s,  -0.000001 s, \u00d7 0.9947,    20 \u00b5s\/rev\nmozilla-central x_revs_x00_added_x_copies             98cbc58cc6bc 446a150332c3 :      7 revs,   0.000661 s,   0.000660 s,  -0.000001 s, \u00d7 0.9985,    94 \u00b5s\/rev\nmozilla-central x_revs_x000_added_x000_copies         3c684b4b8f68 0a5e72d1b479 :      3 revs,   0.003494 s,   0.003542 s,  +0.000048 s, \u00d7 1.0137,  1180 \u00b5s\/rev\nmozilla-central x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.070509 s,   0.071574 s,  +0.001065 s, \u00d7 1.0151, 11929 \u00b5s\/rev\nmozilla-central x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006489 s,   0.006498 s,  +0.000009 s, \u00d7 1.0014,     4 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005070 s,   0.005206 s,  +0.000136 s, \u00d7 1.0268,   126 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x000_copies      7c97034feb78 4407bd0c6330 :   7839 revs,   0.065241 s,   0.065535 s,  +0.000294 s, \u00d7 1.0045,     8 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027284 s,   0.027139 s,  -0.000145 s, \u00d7 0.9947,    44 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_x000_copies    f78c615a656c 96a38b690156 :  30263 revs,   0.203671 s,   0.201924 s,  -0.001747 s, \u00d7 0.9914,     6 \u00b5s\/rev\nmozilla-central x00000_revs_x0000_added_x0000_copies  6832ae71433c 4c222a1d9a00 : 153721 revs,   1.239373 s,   1.257201 s,  +0.017828 s, \u00d7 1.0144,     8 \u00b5s\/rev\nmozilla-central x00000_revs_x00000_added_x000_copies  76caed42cf7c 1daa622bbe42 : 204976 revs,   1.649803 s,   1.663045 s,  +0.013242 s, \u00d7 1.0080,     8 \u00b5s\/rev\nmozilla-try     x_revs_x_added_0_copies               aaf6dde0deb8 9790f499805a :      2 revs,   0.000868 s,   0.000866 s,  -0.000002 s, \u00d7 0.9977,   433 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_0_copies            d8d0222927b4 5bb8ce8c7450 :      2 revs,   0.000885 s,   0.000883 s,  -0.000002 s, \u00d7 0.9977,   441 \u00b5s\/rev\nmozilla-try     x_revs_x_added_x_copies               092fcca11bdb 936255a0384a :      4 revs,   0.000165 s,   0.000163 s,  -0.000002 s, \u00d7 0.9879,    40 \u00b5s\/rev\nmozilla-try     x_revs_x00_added_x_copies             b53d2fadbdb5 017afae788ec :      2 revs,   0.001147 s,   0.001139 s,  -0.000008 s, \u00d7 0.9930,   569 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_x000_copies         20408ad61ce5 6f0ee96e21ad :      1 revs,   0.032885 s,   0.032753 s,  -0.000132 s, \u00d7 0.9960, 32752 \u00b5s\/rev\nmozilla-try     x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.071304 s,   0.073266 s,  +0.001962 s, \u00d7 1.0275, 12211 \u00b5s\/rev\nmozilla-try     x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006506 s,   0.006567 s,  +0.000061 s, \u00d7 1.0094,     4 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005486 s,   0.005427 s,  -0.000059 s, \u00d7 0.9892,   132 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x000_copies      1346fd0130e4 4c65cbdabc1f :   6657 revs,   0.064677 s,   0.064058 s,  -0.000619 s, \u00d7 0.9904,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_0_copies           63519bfd42ee a36a2a865d92 :  40314 revs,   0.306000 s,   0.303320 s,  -0.002680 s, \u00d7 0.9912,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_x_copies           9fe69ff0762d bcabf2a78927 :  38690 revs,   0.288217 s,   0.288456 s,  +0.000239 s, \u00d7 1.0008,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x_copies       156f6e2674f2 4d0f2c178e66 :   8598 revs,   0.086117 s,   0.085925 s,  -0.000192 s, \u00d7 0.9978,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027512 s,   0.027302 s,  -0.000210 s, \u00d7 0.9924,    44 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   1.998239 s,   2.034596 s,  +0.036357 s, \u00d7 1.0182,    20 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,   0.688201 s,   0.694030 s,  +0.005829 s, \u00d7 1.0085,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   4.389428 s,   4.407723 s,  +0.018295 s, \u00d7 1.0042,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs,   0.578736 s,   0.574355 s,  -0.004381 s, \u00d7 0.9924,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   4.363599 s,   4.457827 s,  +0.094228 s, \u00d7 1.0216,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.324129 s,   4.351696 s,  +0.027567 s, \u00d7 1.0064,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.565727 s,   1.570065 s,  +0.004338 s, \u00d7 1.0028,     8 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  86.722016 s,  80.828689 s,  -5.893327 s, \u00d7 0.9320,   352 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  35.113727 s,  34.094064 s,  -1.019663 s, \u00d7 0.9710,    89 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  27.397070 s,  27.435529 s,  +0.038459 s, \u00d7 1.0014,    59 \u00b5s\/rev","testPlan":"","lineCount":"6","dependsOn":["9654"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146592","dateCreated":"1610147772","dateModified":"1610147772"},{"type":"update","diffId":"24680","author":"baymax","id":"146591","dateCreated":"1610147772","dateModified":"1610147772"},{"type":"accept","author":"Alphare","id":"146301","dateCreated":"1610115189","dateModified":"1610115189"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145995","dateCreated":"1609837667","dateModified":"1609837667"},{"type":"update","diffId":"24589","author":"baymax","id":"145994","dateCreated":"1609837667","dateModified":"1609837667"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145647","dateCreated":"1608691606","dateModified":"1608691606"},{"type":"update","diffId":"24505","author":"baymax","id":"145646","dateCreated":"1608691606","dateModified":"1608691606"},{"type":"update","diffId":"24494","author":"marmoute","id":"145621","dateCreated":"1608689553","dateModified":"1608689553"},{"type":"update","diffId":"24479","author":"marmoute","id":"145519","dateCreated":"1608589757","dateModified":"1608589757"}],"dateCreated":"1608589757","dateModified":"1610147772","status":"Needs Review"},{"id":"9654","callsign":"HG","title":"copies-rust: make more use of the new comparison property","author":"marmoute","summary":"We deal with the \"both are the same\" sooner and simplify the rest of the\nconditional.","testPlan":"","lineCount":"42","dependsOn":["9653"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146590","dateCreated":"1610147770","dateModified":"1610147770"},{"type":"update","diffId":"24679","author":"baymax","id":"146589","dateCreated":"1610147770","dateModified":"1610147770"},{"type":"accept","author":"Alphare","id":"146300","dateCreated":"1610114903","dateModified":"1610114903"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145993","dateCreated":"1609837664","dateModified":"1609837664"},{"type":"update","diffId":"24588","author":"baymax","id":"145992","dateCreated":"1609837664","dateModified":"1609837664"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145645","dateCreated":"1608691603","dateModified":"1608691603"},{"type":"update","diffId":"24504","author":"baymax","id":"145644","dateCreated":"1608691603","dateModified":"1608691603"},{"type":"update","diffId":"24493","author":"marmoute","id":"145620","dateCreated":"1608689548","dateModified":"1608689548"},{"type":"update","diffId":"24478","author":"marmoute","id":"145511","dateCreated":"1608589752","dateModified":"1608589752"}],"dateCreated":"1608589752","dateModified":"1610147770","status":"Needs Review"},{"id":"9653","callsign":"HG","title":"copies-rust: implement PartialEqual manually","author":"marmoute","summary":"Now that we know that each (dest, rev) pair has at most a unique CopySource, we\ncan simplify comparison a lot.\n\nThis \"simple\" step buy a good share of the previous slowdown back in some case:\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  43.304637 s,  34.443661 s,  -8.860976 s, \u00d7 0.7954,    90 \u00b5s\/rev\n\n\nFull benchmark:\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmercurial       x_revs_x_added_0_copies               ad6b123de1c7 39cfcef4f463 :      1 revs,   0.000043 s,   0.000043 s,  +0.000000 s, \u00d7 1.0000,    43 \u00b5s\/rev\nmercurial       x_revs_x_added_x_copies               2b1c78674230 0c1d10351869 :      6 revs,   0.000114 s,   0.000117 s,  +0.000003 s, \u00d7 1.0263,    19 \u00b5s\/rev\nmercurial       x000_revs_x000_added_x_copies         81f8ff2a9bf2 dd3267698d84 :   1032 revs,   0.004937 s,   0.004892 s,  -0.000045 s, \u00d7 0.9909,     4 \u00b5s\/rev\npypy            x_revs_x_added_0_copies               aed021ee8ae8 099ed31b181b :      9 revs,   0.000339 s,   0.000196 s,  -0.000143 s, \u00d7 0.5782,    21 \u00b5s\/rev\npypy            x_revs_x000_added_0_copies            4aa4e1f8e19a 359343b9ac0e :      1 revs,   0.000049 s,   0.000050 s,  +0.000001 s, \u00d7 1.0204,    50 \u00b5s\/rev\npypy            x_revs_x_added_x_copies               ac52eb7bbbb0 72e022663155 :      7 revs,   0.000202 s,   0.000117 s,  -0.000085 s, \u00d7 0.5792,    16 \u00b5s\/rev\npypy            x_revs_x00_added_x_copies             c3b14617fbd7 ace7255d9a26 :      1 revs,   0.000409 s,   0.6f1f4a s,  -0.000087 s, \u00d7 0.7873,   322 \u00b5s\/rev\npypy            x_revs_x000_added_x000_copies         df6f7a526b60 a83dc6a2d56f :      6 revs,   0.011984 s,   0.011949 s,  -0.000035 s, \u00d7 0.9971,  1991 \u00b5s\/rev\npypy            x000_revs_xx00_added_0_copies         89a76aede314 2f22446ff07e :   4785 revs,   0.050820 s,   0.050802 s,  -0.000018 s, \u00d7 0.9996,    10 \u00b5s\/rev\npypy            x000_revs_x000_added_x_copies         8a3b5bfd266e 2c68e87c3efe :   6780 revs,   0.087953 s,   0.088090 s,  +0.000137 s, \u00d7 1.0016,    12 \u00b5s\/rev\npypy            x000_revs_x000_added_x000_copies      89a76aede314 7b3dda341c84 :   5441 revs,   0.062902 s,   0.062079 s,  -0.000823 s, \u00d7 0.9869,    11 \u00b5s\/rev\npypy            x0000_revs_x_added_0_copies           d1defd0dc478 c9cb1334cc78 :  43645 revs,   0.679234 s,   0.635337 s,  -0.043897 s, \u00d7 0.9354,    14 \u00b5s\/rev\npypy            x0000_revs_xx000_added_0_copies       bf2c629d0071 4ffed77c095c :      2 revs,   0.013095 s,   0.013262 s,  +0.000167 s, \u00d7 1.0128,  6631 \u00b5s\/rev\npypy            x0000_revs_xx000_added_x000_copies    08ea3258278e d9fa043f30c0 :  11316 revs,   0.120910 s,   0.120085 s,  -0.000825 s, \u00d7 0.9932,    10 \u00b5s\/rev\nnetbeans        x_revs_x_added_0_copies               fb0955ffcbcd a01e9239f9e7 :      2 revs,   0.000087 s,   0.000085 s,  -0.000002 s, \u00d7 0.9770,    42 \u00b5s\/rev\nnetbeans        x_revs_x000_added_0_copies            6f360122949f 20eb231cc7d0 :      2 revs,   0.000107 s,   0.000110 s,  +0.000003 s, \u00d7 1.0280,    55 \u00b5s\/rev\nnetbeans        x_revs_x_added_x_copies               1ada3faf6fb6 5a39d12eecf4 :      3 revs,   0.000186 s,   0.000177 s,  -0.000009 s, \u00d7 0.9516,    59 \u00b5s\/rev\nnetbeans        x_revs_x00_added_x_copies             35be93ba1e2c 9eec5e90c05f :      9 revs,   0.000754 s,   0.000743 s,  -0.000011 s, \u00d7 0.9854,    82 \u00b5s\/rev\nnetbeans        x000_revs_xx00_added_0_copies         eac3045b4fdd 51d4ae7f1290 :   1421 revs,   0.010443 s,   0.010168 s,  -0.000275 s, \u00d7 0.9737,     7 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x_copies         e2063d266acd 6081d72689dc :   1533 revs,   0.015697 s,   0.015946 s,  +0.000249 s, \u00d7 1.0159,    10 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x000_copies      ff453e9fee32 411350406ec2 :   5750 revs,   0.063528 s,   0.062712 s,  -0.000816 s, \u00d7 0.9872,    10 \u00b5s\/rev\nnetbeans        x0000_revs_xx000_added_x000_copies    588c2d1ced70 1aad62e59ddd :  66949 revs,   0.545515 s,   0.523832 s,  -0.021683 s, \u00d7 0.9603,     7 \u00b5s\/rev\nmozilla-central x_revs_x_added_0_copies               3697f962bb7b 7015fcdd43a2 :      2 revs,   0.000089 s,   0.000090 s,  +0.000001 s, \u00d7 1.0112,    45 \u00b5s\/rev\nmozilla-central x_revs_x000_added_0_copies            dd390860c6c9 40d0c5bed75d :      8 revs,   0.000265 s,   0.000264 s,  -0.000001 s, \u00d7 0.9962,    33 \u00b5s\/rev\nmozilla-central x_revs_x_added_x_copies               8d198483ae3b 14207ffc2b2f :      9 revs,   0.000381 s,   0.000187 s,  -0.000194 s, \u00d7 0.4908,    20 \u00b5s\/rev\nmozilla-central x_revs_x00_added_x_copies             98cbc58cc6bc 446a150332c3 :      7 revs,   0.000672 s,   0.000665 s,  -0.000007 s, \u00d7 0.9896,    95 \u00b5s\/rev\nmozilla-central x_revs_x000_added_x000_copies         3c684b4b8f68 0a5e72d1b479 :      3 revs,   0.003497 s,   0.003556 s,  +0.000059 s, \u00d7 1.0169,  1185 \u00b5s\/rev\nmozilla-central x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.073204 s,   0.071345 s,  -0.001859 s, \u00d7 0.9746, 11890 \u00b5s\/rev\nmozilla-central x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006482 s,   0.006551 s,  +0.000069 s, \u00d7 1.0106,     4 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005066 s,   0.005078 s,  +0.000012 s, \u00d7 1.0024,   123 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x000_copies      7c97034feb78 4407bd0c6330 :   7839 revs,   0.065707 s,   0.065823 s,  +0.000116 s, \u00d7 1.0018,     8 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.026800 s,   0.027050 s,  +0.000250 s, \u00d7 1.0093,    43 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_x000_copies    f78c615a656c 96a38b690156 :  30263 revs,   0.203856 s,   0.202443 s,  -0.001413 s, \u00d7 0.9931,     6 \u00b5s\/rev\nmozilla-central x00000_revs_x0000_added_x0000_copies  6832ae71433c 4c222a1d9a00 : 153721 revs,   1.293394 s,   1.261583 s,  -0.031811 s, \u00d7 0.9754,     8 \u00b5s\/rev\nmozilla-central x00000_revs_x00000_added_x000_copies  76caed42cf7c 1daa622bbe42 : 204976 revs,   1.698239 s,   1.643869 s,  -0.054370 s, \u00d7 0.9680,     8 \u00b5s\/rev\nmozilla-try     x_revs_x_added_0_copies               aaf6dde0deb8 9790f499805a :      2 revs,   0.000875 s,   0.000868 s,  -0.000007 s, \u00d7 0.9920,   434 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_0_copies            d8d0222927b4 5bb8ce8c7450 :      2 revs,   0.000891 s,   0.000887 s,  -0.000004 s, \u00d7 0.9955,   443 \u00b5s\/rev\nmozilla-try     x_revs_x_added_x_copies               092fcca11bdb 936255a0384a :      4 revs,   0.000292 s,   0.000168 s,  -0.000124 s, \u00d7 0.5753,    42 \u00b5s\/rev\nmozilla-try     x_revs_x00_added_x_copies             b53d2fadbdb5 017afae788ec :      2 revs,   0.003939 s,   0.001160 s,  -0.002779 s, \u00d7 0.2945,   580 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_x000_copies         20408ad61ce5 6f0ee96e21ad :      1 revs,   0.033027 s,   0.033016 s,  -0.000011 s, \u00d7 0.9997, 33016 \u00b5s\/rev\nmozilla-try     x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.073703 s,   0.073312 s,  -0.39ae31 s, \u00d7 0.9947, 12218 \u00b5s\/rev\nmozilla-try     x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006469 s,   0.006485 s,  +0.000016 s, \u00d7 1.0025,     4 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005278 s,   0.005494 s,  +0.000216 s, \u00d7 1.0409,   134 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x000_copies      1346fd0130e4 4c65cbdabc1f :   6657 revs,   0.064995 s,   0.064879 s,  -0.000116 s, \u00d7 0.9982,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_0_copies           63519bfd42ee a36a2a865d92 :  40314 revs,   0.301041 s,   0.301469 s,  +0.000428 s, \u00d7 1.0014,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_x_copies           9fe69ff0762d bcabf2a78927 :  38690 revs,   0.285575 s,   0.297113 s,  +0.011538 s, \u00d7 1.0404,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x_copies       156f6e2674f2 4d0f2c178e66 :   8598 revs,   0.085597 s,   0.085890 s,  +0.000293 s, \u00d7 1.0034,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027118 s,   0.027718 s,  +0.000600 s, \u00d7 1.0221,    45 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   2.119204 s,   2.048949 s,  -0.070255 s, \u00d7 0.9668,    21 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,   0.701479 s,   0.685924 s,  -0.015555 s, \u00d7 0.9778,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   4.482399 s,   4.482891 s,  +0.000492 s, \u00d7 1.0001,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs,   0.574082 s,   0.577633 s,  +0.003551 s, \u00d7 1.0062,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   4.480366 s,   4.397816 s,  -0.082550 s, \u00d7 0.9816,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.369070 s,   4.370538 s,  +0.001468 s, \u00d7 1.0003,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.592506 s,   1.570439 s,  -0.022067 s, \u00d7 0.9861,     8 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  87.824489 s,  88.388512 s,  +0.564023 s, \u00d7 1.0064,   386 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  43.304637 s,  34.443661 s,  -8.860976 s, \u00d7 0.7954,    90 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  33.853687 s,  27.370148 s,  -6.483539 s, \u00d7 0.8085,    59 \u00b5s\/rev","testPlan":"","lineCount":"17","dependsOn":["9652"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146588","dateCreated":"1610147768","dateModified":"1610147768"},{"type":"update","diffId":"24678","author":"baymax","id":"146587","dateCreated":"1610147768","dateModified":"1610147768"},{"type":"accept","author":"Alphare","id":"146298","dateCreated":"1610114482","dateModified":"1610114482"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145991","dateCreated":"1609837661","dateModified":"1609837661"},{"type":"update","diffId":"24587","author":"baymax","id":"145990","dateCreated":"1609837661","dateModified":"1609837661"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145643","dateCreated":"1608691601","dateModified":"1608691601"},{"type":"update","diffId":"24503","author":"baymax","id":"145642","dateCreated":"1608691601","dateModified":"1608691601"},{"type":"update","diffId":"24492","author":"marmoute","id":"145619","dateCreated":"1608689544","dateModified":"1608689544"},{"type":"update","diffId":"24477","author":"marmoute","id":"145502","dateCreated":"1608589747","dateModified":"1608589747"}],"dateCreated":"1608589747","dateModified":"1610147768","status":"Needs Review"},{"id":"9652","callsign":"HG","title":"copies-rust: record \"overwritten\" information from both side on delete","author":"marmoute","summary":"With this change, we can ensure every (`dest`, `rev`) points to the same value,\nmaking a lots of comparison simpler.","testPlan":"","lineCount":"19","dependsOn":["9651"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146586","dateCreated":"1610147766","dateModified":"1610147766"},{"type":"update","diffId":"24677","author":"baymax","id":"146585","dateCreated":"1610147766","dateModified":"1610147766"},{"type":"accept","author":"Alphare","id":"146297","dateCreated":"1610114284","dateModified":"1610114284"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145989","dateCreated":"1609837659","dateModified":"1609837659"},{"type":"update","diffId":"24586","author":"baymax","id":"145988","dateCreated":"1609837659","dateModified":"1609837659"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145641","dateCreated":"1608691599","dateModified":"1608691599"},{"type":"update","diffId":"24502","author":"baymax","id":"145640","dateCreated":"1608691599","dateModified":"1608691599"},{"type":"update","diffId":"24491","author":"marmoute","id":"145618","dateCreated":"1608689539","dateModified":"1608689539"},{"type":"update","diffId":"24476","author":"marmoute","id":"145494","dateCreated":"1608589740","dateModified":"1608589740"}],"dateCreated":"1608589740","dateModified":"1610147766","status":"Needs Review"},{"id":"9651","callsign":"HG","title":"copies-rust: refactor the \"deletion\" case","author":"marmoute","summary":"We rearrange the code to single out the case where information need to be\noverwritten on both side of the merge. This open the way to better dealing with\nthis case.","testPlan":"","lineCount":"41","dependsOn":["9650"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146584","dateCreated":"1610147763","dateModified":"1610147763"},{"type":"update","diffId":"24676","author":"baymax","id":"146583","dateCreated":"1610147763","dateModified":"1610147763"},{"type":"inline","comment":"Yeah, I meant `Option::and`, but it seems like the compiler is not able to infer the closure types. So let's keep it that way.","replyTo":"146329","isNewFile":"1","line":"521","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24585","author":"Alphare","id":"146331","dateCreated":"1610120614","dateModified":"1610120614"},{"type":"accept","author":"Alphare","id":"146330","dateCreated":"1610120614","dateModified":"1610120614"},{"type":"inline","comment":"This would create Option of Option, so I';ll keep the current code.","replyTo":"146309","isNewFile":"1","line":"521","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24585","author":"marmoute","id":"146329","dateCreated":"1610120531","dateModified":"1610120531"},{"type":"inline","comment":"```\nlet p1_entry = p1_copies.as_mut().map(\n    |copies| match copies.entry(deleted) {\n        Entry::Occupied(e) => Some(e),\n        Entry::Vacant(_) => None,\n    }\n);\n```\nYou need `as_mut()` as well.","replyTo":"146308","isNewFile":"1","line":"521","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24585","author":"Alphare","id":"146309","dateCreated":"1610118214","dateModified":"1610118214"},{"type":"inline","comment":"<suspiciously looking at `map(\u2026)`>\n\nHow would that work ?","replyTo":"146293","isNewFile":"1","line":"521","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24585","author":"marmoute","id":"146308","dateCreated":"1610117132","dateModified":"1610117132"},{"type":"inline","comment":"This would be better as `p1_copies.map(...)`","replyTo":null,"isNewFile":"1","line":"521","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24585","author":"Alphare","id":"146293","dateCreated":"1610113954","dateModified":"1610113954"},{"type":"reject","author":"Alphare","id":"146292","dateCreated":"1610113954","dateModified":"1610113954"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145987","dateCreated":"1609837657","dateModified":"1609837657"},{"type":"update","diffId":"24585","author":"baymax","id":"145986","dateCreated":"1609837657","dateModified":"1609837657"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145639","dateCreated":"1608691598","dateModified":"1608691598"},{"type":"update","diffId":"24501","author":"baymax","id":"145638","dateCreated":"1608691598","dateModified":"1608691598"},{"type":"update","diffId":"24490","author":"marmoute","id":"145617","dateCreated":"1608689534","dateModified":"1608689534"},{"type":"update","diffId":"24475","author":"marmoute","id":"145486","dateCreated":"1608589734","dateModified":"1608589734"}],"dateCreated":"1608589734","dateModified":"1610147763","status":"Needs Review"},{"id":"9650","callsign":"HG","title":"copies-rust: process copy information of both parent at the same time","author":"marmoute","summary":"This avoid a double iteration and this open the way to a better handing of\ndeletion. That better handling of deletion is the core reason we are doing this\nrefactoring.","testPlan":"","lineCount":"93","dependsOn":["9649"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146582","dateCreated":"1610147761","dateModified":"1610147761"},{"type":"update","diffId":"24675","author":"baymax","id":"146581","dateCreated":"1610147761","dateModified":"1610147761"},{"type":"accept","author":"Alphare","id":"146333","dateCreated":"1610120649","dateModified":"1610120649"},{"type":"inline","comment":"You're right, I'm blind. :)","replyTo":"146304","isNewFile":"1","line":"494","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"Alphare","id":"146310","dateCreated":"1610118511","dateModified":"1610118511"},{"type":"inline","comment":"m'okay","replyTo":"146277","isNewFile":"1","line":"472","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"marmoute","id":"146306","dateCreated":"1610116919","dateModified":"1610116919"},{"type":"inline","comment":"sweet","replyTo":"146278","isNewFile":"1","line":"477","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"marmoute","id":"146305","dateCreated":"1610116918","dateModified":"1610116918"},{"type":"inline","comment":"The clone is needed for both remove and Copied Case. We could try to be smarter, only cloning at the first edit, but the underlying data are im-rs:ordmap so cloning is cheap.","replyTo":"146279","isNewFile":"1","line":"494","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"marmoute","id":"146304","dateCreated":"1610116918","dateModified":"1610116918"},{"type":"inline","comment":"Looks like you're doing a clone that isn't needed unless we're in the `::Removed` case and then unwrapping.","replyTo":null,"isNewFile":"1","line":"494","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"Alphare","id":"146279","dateCreated":"1610113690","dateModified":"1610113690"},{"type":"inline","comment":"This is `let mut p1_copies = base_p1_copies.clone();`","replyTo":null,"isNewFile":"1","line":"477","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"Alphare","id":"146278","dateCreated":"1610113690","dateModified":"1610113690"},{"type":"inline","comment":"I'd rather use a `if let (None, None) = (&base_p1_copies, &base_p2_copies)` , but it's not a big deal.","replyTo":null,"isNewFile":"1","line":"472","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24584","author":"Alphare","id":"146277","dateCreated":"1610113690","dateModified":"1610113690"},{"type":"reject","author":"Alphare","id":"146276","dateCreated":"1610113690","dateModified":"1610113690"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145985","dateCreated":"1609837655","dateModified":"1609837655"},{"type":"update","diffId":"24584","author":"baymax","id":"145984","dateCreated":"1609837655","dateModified":"1609837655"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145637","dateCreated":"1608691596","dateModified":"1608691596"},{"type":"update","diffId":"24500","author":"baymax","id":"145636","dateCreated":"1608691596","dateModified":"1608691596"},{"type":"update","diffId":"24489","author":"marmoute","id":"145616","dateCreated":"1608689529","dateModified":"1608689529"},{"type":"update","diffId":"24474","author":"marmoute","id":"145478","dateCreated":"1608589728","dateModified":"1608589728"}],"dateCreated":"1608589728","dateModified":"1610147761","status":"Needs Review"},{"id":"9649","callsign":"HG","title":"copies-rust: yield both p1 and p2 copies in `ChangedFiles.actions()`","author":"marmoute","summary":"Instead of filtering the relevant parent inside de ChangedFiles method, we now\nyield all copies information and let the caller do the filtering. Soon, the\nfiltering will be replaced by dispatching.","testPlan":"","lineCount":"53","dependsOn":["9648"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146580","dateCreated":"1610147758","dateModified":"1610147758"},{"type":"update","diffId":"24674","author":"baymax","id":"146579","dateCreated":"1610147758","dateModified":"1610147758"},{"type":"accept","author":"Alphare","id":"146274","dateCreated":"1610112797","dateModified":"1610112797"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145983","dateCreated":"1609837654","dateModified":"1609837654"},{"type":"update","diffId":"24583","author":"baymax","id":"145982","dateCreated":"1609837654","dateModified":"1609837654"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145635","dateCreated":"1608691595","dateModified":"1608691595"},{"type":"update","diffId":"24499","author":"baymax","id":"145634","dateCreated":"1608691595","dateModified":"1608691595"},{"type":"update","diffId":"24488","author":"marmoute","id":"145615","dateCreated":"1608689524","dateModified":"1608689524"},{"type":"update","diffId":"24473","author":"marmoute","id":"145470","dateCreated":"1608589723","dateModified":"1608589723"}],"dateCreated":"1608589723","dateModified":"1610147758","status":"Needs Review"},{"id":"9648","callsign":"HG","title":"copies-rust: extract the processing of a single copy information","author":"marmoute","summary":"This will make it easy to process copy from both p1 and p2 in the same\n`add_from_changes` call.","testPlan":"","lineCount":"71","dependsOn":["9647"],"reviewers":["SimonSapin","Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146578","dateCreated":"1610147756","dateModified":"1610147756"},{"type":"update","diffId":"24673","author":"baymax","id":"146577","dateCreated":"1610147756","dateModified":"1610147756"},{"type":"accept","author":"Alphare","id":"146273","dateCreated":"1610112709","dateModified":"1610112709"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145981","dateCreated":"1609837652","dateModified":"1609837652"},{"type":"update","diffId":"24582","author":"baymax","id":"145980","dateCreated":"1609837652","dateModified":"1609837652"},{"type":"accept","author":"SimonSapin","id":"145773","dateCreated":"1609163431","dateModified":"1609163431"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145633","dateCreated":"1608691594","dateModified":"1608691594"},{"type":"update","diffId":"24498","author":"baymax","id":"145632","dateCreated":"1608691594","dateModified":"1608691594"},{"type":"update","diffId":"24487","author":"marmoute","id":"145614","dateCreated":"1608689519","dateModified":"1608689519"},{"type":"update","diffId":"24472","author":"marmoute","id":"145462","dateCreated":"1608589718","dateModified":"1608589718"}],"dateCreated":"1608589718","dateModified":"1610147756","status":"Needs Review"},{"id":"9647","callsign":"HG","title":"copies-rust: use matching to select the final copies information","author":"marmoute","summary":"This is a bit more idiomatic and this prepare a future refactoring where\nInternalCopies from both parent would be updated at the same time.","testPlan":"","lineCount":"54","dependsOn":["9646"],"reviewers":["SimonSapin","Alphare"],"ccs":["Alphare","SimonSapin","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146576","dateCreated":"1610147755","dateModified":"1610147755"},{"type":"update","diffId":"24672","author":"baymax","id":"146575","dateCreated":"1610147755","dateModified":"1610147755"},{"type":"comment","comment":"Same comment as Simon, but I suppose this does not live long.","author":"Alphare","id":"146272","dateCreated":"1610112682","dateModified":"1610112682"},{"type":"accept","author":"Alphare","id":"146271","dateCreated":"1610112682","dateModified":"1610112682"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145979","dateCreated":"1609837651","dateModified":"1609837651"},{"type":"update","diffId":"24581","author":"baymax","id":"145978","dateCreated":"1609837651","dateModified":"1609837651"},{"type":"comment","comment":"These first two `match` expressions could be calls to `Option::map` instead, but this is fine.","author":"SimonSapin","id":"145772","dateCreated":"1609163350","dateModified":"1609163350"},{"type":"accept","author":"SimonSapin","id":"145771","dateCreated":"1609163350","dateModified":"1609163350"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145631","dateCreated":"1608691592","dateModified":"1608691592"},{"type":"update","diffId":"24497","author":"baymax","id":"145630","dateCreated":"1608691592","dateModified":"1608691592"},{"type":"update","diffId":"24486","author":"marmoute","id":"145613","dateCreated":"1608689514","dateModified":"1608689514"},{"type":"update","diffId":"24471","author":"marmoute","id":"145454","dateCreated":"1608589712","dateModified":"1608589712"}],"dateCreated":"1608589712","dateModified":"1610147755","status":"Needs Review"},{"id":"9646","callsign":"HG","title":"copies-rust: get the parents' copies earlier","author":"marmoute","summary":"This remove some conditional nesting and prepare for future work were we will\nunify the handling of copies from p1 and p2.","testPlan":"","lineCount":"91","dependsOn":["9645"],"reviewers":["pulkit","Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146574","dateCreated":"1610147754","dateModified":"1610147754"},{"type":"update","diffId":"24671","author":"baymax","id":"146573","dateCreated":"1610147754","dateModified":"1610147754"},{"type":"accept","author":"Alphare","id":"146269","dateCreated":"1610112612","dateModified":"1610112612"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145977","dateCreated":"1609837650","dateModified":"1609837650"},{"type":"update","diffId":"24580","author":"baymax","id":"145976","dateCreated":"1609837650","dateModified":"1609837650"},{"type":"accept","author":"pulkit","id":"145716","dateCreated":"1609143500","dateModified":"1609143500"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145629","dateCreated":"1608691591","dateModified":"1608691591"},{"type":"update","diffId":"24496","author":"baymax","id":"145628","dateCreated":"1608691591","dateModified":"1608691591"},{"type":"update","diffId":"24485","author":"marmoute","id":"145612","dateCreated":"1608689509","dateModified":"1608689509"},{"type":"update","diffId":"24470","author":"marmoute","id":"145446","dateCreated":"1608589707","dateModified":"1608589707"}],"dateCreated":"1608589707","dateModified":"1610147754","status":"Accepted"},{"id":"9135","callsign":"HG","title":"doc: Generate separate commands\/topics\/extension web pages.","author":"ludovicchabant","summary":"","testPlan":"","lineCount":"507","dependsOn":[],"reviewers":[],"ccs":["marmoute","durin42","mercurial-patches"],"actions":[{"type":"comment","comment":"@ludovicchabant gentle ping","author":"marmoute","id":"146369","dateCreated":"1610124822","dateModified":"1610124822"},{"type":"comment","comment":"I'm fine with this as long as it still works on Python 3. Can you confirm this works under Python 3? Maybe rebase it to `@` for completeness, since it's been a while.\n\nSorry for slow responses.","author":"durin42","id":"145929","dateCreated":"1609556764","dateModified":"1609556764"},{"type":"comment","comment":"Derp... phabricator didn't send me any email notification....\n\nAnyway, if the implementation is roughly ok we can do a code review and queue it for next release. If not, I can redo it using a better approach? I'm not sure what \"RFC\" and \"landing\" mean in the specific context of the mercurial release workflow, so whichever one is more appropriate is fine by me!  The main things I'd like to have feedback on are:\n\n1) The method I'm using here requires a recent Make (for instance, the one that ships by default on macOS won't work). I don't know if there's a better way to do this?\n2) This generates a bunch of intermediate and final files, which increases the `make docs` time. I don't know if process time is an issue here, or if it's OK because it's run only once per release?\n3) I took a bit of creative freedom for the format of the new pages. This is easy to iterate upon a bit later but it's worth taking a look at the output in case you have any opinions.\n\nThanks!","author":"ludovicchabant","id":"142904","dateCreated":"1606949877","dateModified":"1606950187"},{"type":"comment","comment":"I like it. Did you intend this as an RFC, or for landing?","author":"durin42","id":"138354","dateCreated":"1602704486","dateModified":"1602704486"},{"type":"comment","comment":"Hi there... this patch is a proof of concept, and probably entirely the wrong approach since I was learning Makefiles almost from scratch as I was doing it (and then by the end realized it only works with recent versions of Make). But I'd like to put the basic idea of the change up for review at least before I continue working on it.\n\nThe basic idea is that the [[ https:\/\/www.mercurial-scm.org\/doc\/hg.1.html | Mercurial reference page ]] is too damn big and unwieldy. Its size also makes it hard to search for something only for a given command. One could search through the help output in a terminal but there is tremendous value in having a well organized and friendly website. Anyway, this change makes it possible to spit out separate web pages for each command, topic, and extension, along with a classified index page that links to all of them.\n\nThanks","author":"ludovicchabant","id":"137028","dateCreated":"1601502000","dateModified":"1601502037"},{"type":"update","diffId":"22957","author":"ludovicchabant","id":"137022","dateCreated":"1601501721","dateModified":"1601501721"}],"dateCreated":"1601501721","dateModified":"1610124822","status":"Needs Review"},{"id":"9645","callsign":"HG","title":"copies-rust: remove the ancestor Oracle logic","author":"marmoute","summary":"We are not doing any `is_ancestor` call anymore. So we can drop that logic and\nassociated arguments.","testPlan":"","lineCount":"124","dependsOn":["9644"],"reviewers":["pulkit","Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146327","dateCreated":"1610119573","dateModified":"1610119573"},{"type":"update","diffId":"24642","author":"baymax","id":"146326","dateCreated":"1610119573","dateModified":"1610119573"},{"type":"comment","comment":"Finally!","author":"Alphare","id":"146268","dateCreated":"1610111770","dateModified":"1610111770"},{"type":"accept","author":"Alphare","id":"146267","dateCreated":"1610111770","dateModified":"1610111770"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146032","dateCreated":"1609856257","dateModified":"1609856257"},{"type":"update","diffId":"24601","author":"baymax","id":"146031","dateCreated":"1609856257","dateModified":"1609856257"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145975","dateCreated":"1609836771","dateModified":"1609836771"},{"type":"update","diffId":"24579","author":"baymax","id":"145974","dateCreated":"1609836771","dateModified":"1609836771"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145655","dateCreated":"1608713421","dateModified":"1608713421"},{"type":"update","diffId":"24509","author":"baymax","id":"145654","dateCreated":"1608713421","dateModified":"1608713421"},{"type":"update","diffId":"24484","author":"marmoute","id":"145611","dateCreated":"1608689505","dateModified":"1608689505"},{"type":"accept","author":"pulkit","id":"145596","dateCreated":"1608646456","dateModified":"1608646456"},{"type":"update","diffId":"24469","author":"marmoute","id":"145438","dateCreated":"1608589703","dateModified":"1608589703"}],"dateCreated":"1608589703","dateModified":"1610119573","status":"Accepted"},{"id":"9644","callsign":"HG","title":"copies-rust: track \"overwrites\" directly within CopySource","author":"marmoute","summary":"Overwrite are \"rare enough\" that explicitly keeping track of them is going to be\n\"cheap\", or at least much cheaper that issuing many `is_ancestor` calls.\n\nEven a simple implementation using no specific optimisation (eg: using the\ngeneric HashSet type) yield good result in most cases.\n\nThey are interesting optimization to can do on top of that. We will implement\nthem in later changesets.\n\nWe tried different approach to speed up the overwrite detection and this one\nseems the most promising. Without further optimization, we already see sizable\nspeedup on various cases.\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   5.138169 s,   4.482399 s,  -0.655770 s, \u00d7 0.8724,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   5.127809 s,   4.480366 s,  -0.647443 s, \u00d7 0.8737,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.971136 s,   4.369070 s,  -0.602066 s, \u00d7 0.8789,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.741678 s,   1.592506 s,  -0.149172 s, \u00d7 0.9144,     8 \u00b5s\/rev\n\nHowever, some of the case doing a lot of overwrite get significantly slower.\nThe one with a really problematic slowdown are the special \"head reducing\" merge\nin mozilla-try so I am not too worried about them. In addition, further\nchangeset are going to improve the performance of all this.\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   1.343373 s,   2.119204 s,  +0.775831 s, \u00d7 1.5775,    21 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  40.314822 s,  87.824489 s, +47.509667 s, \u00d7 2.1785,   383 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  20.048029 s,  43.304637 s, +23.256608 s, \u00d7 2.1600,   113 \u00b5s\/rev\n\n\nFull benchmark below:\n\nRepo            Case                                  Source-Rev   Dest-Rev      # of revisions  old time    new time      Difference    Factor    time per rev\n---------------------------------------------------------------------------------------------------------------------------------------------------------------\nmercurial       x_revs_x_added_0_copies               ad6b123de1c7 39cfcef4f463 :      1 revs,   0.000042 s,   0.000043 s,  +0.000001 s, \u00d7 1.0238,    43 \u00b5s\/rev\nmercurial       x_revs_x_added_x_copies               2b1c78674230 0c1d10351869 :      6 revs,   0.000110 s,   0.000114 s,  +0.000004 s, \u00d7 1.0364,    19 \u00b5s\/rev\nmercurial       x000_revs_x000_added_x_copies         81f8ff2a9bf2 dd3267698d84 :   1032 revs,   0.004945 s,   0.004937 s,  -0.000008 s, \u00d7 0.9984,     4 \u00b5s\/rev\npypy            x_revs_x_added_0_copies               aed021ee8ae8 099ed31b181b :      9 revs,   0.000192 s,   0.000339 s,  +0.000147 s, \u00d7 1.7656,    37 \u00b5s\/rev\npypy            x_revs_x000_added_0_copies            4aa4e1f8e19a 359343b9ac0e :      1 revs,   0.000049 s,   0.000049 s,  +0.000000 s, \u00d7 1.0000,    49 \u00b5s\/rev\npypy            x_revs_x_added_x_copies               ac52eb7bbbb0 72e022663155 :      7 revs,   0.000112 s,   0.000202 s,  +0.000090 s, \u00d7 1.8036,    28 \u00b5s\/rev\npypy            x_revs_x00_added_x_copies             c3b14617fbd7 ace7255d9a26 :      1 revs,   0.000323 s,   0.000409 s,  +0.000086 s, \u00d7 1.2663,   409 \u00b5s\/rev\npypy            x_revs_x000_added_x000_copies         df6f7a526b60 a83dc6a2d56f :      6 revs,   0.010042 s,   0.011984 s,  +0.001942 s, \u00d7 1.1934,  1997 \u00b5s\/rev\npypy            x000_revs_xx00_added_0_copies         89a76aede314 2f22446ff07e :   4785 revs,   0.049813 s,   0.050820 s,  +0.001007 s, \u00d7 1.0202,    10 \u00b5s\/rev\npypy            x000_revs_x000_added_x_copies         8a3b5bfd266e 2c68e87c3efe :   6780 revs,   0.079937 s,   0.087953 s,  +0.008016 s, \u00d7 1.1003,    12 \u00b5s\/rev\npypy            x000_revs_x000_added_x000_copies      89a76aede314 7b3dda341c84 :   5441 revs,   0.059412 s,   0.062902 s,  +0.003490 s, \u00d7 1.0587,    11 \u00b5s\/rev\npypy            x0000_revs_x_added_0_copies           d1defd0dc478 c9cb1334cc78 :  43645 revs,   0.533769 s,   0.679234 s,  +0.145465 s, \u00d7 1.2725,    15 \u00b5s\/rev\npypy            x0000_revs_xx000_added_0_copies       bf2c629d0071 4ffed77c095c :      2 revs,   0.013147 s,   0.013095 s,  -0.000052 s, \u00d7 0.9960,  6547 \u00b5s\/rev\npypy            x0000_revs_xx000_added_x000_copies    08ea3258278e d9fa043f30c0 :  11316 revs,   0.110680 s,   0.120910 s,  +0.010230 s, \u00d7 1.0924,    10 \u00b5s\/rev\nnetbeans        x_revs_x_added_0_copies               fb0955ffcbcd a01e9239f9e7 :      2 revs,   0.000085 s,   0.000087 s,  +0.000002 s, \u00d7 1.0235,    43 \u00b5s\/rev\nnetbeans        x_revs_x000_added_0_copies            6f360122949f 20eb231cc7d0 :      2 revs,   0.000107 s,   0.000107 s,  +0.000000 s, \u00d7 1.0000,    53 \u00b5s\/rev\nnetbeans        x_revs_x_added_x_copies               1ada3faf6fb6 5a39d12eecf4 :      3 revs,   0.000175 s,   0.000186 s,  +0.000011 s, \u00d7 1.0629,    62 \u00b5s\/rev\nnetbeans        x_revs_x00_added_x_copies             35be93ba1e2c 9eec5e90c05f :      9 revs,   0.000720 s,   0.000754 s,  +0.000034 s, \u00d7 1.0472,    83 \u00b5s\/rev\nnetbeans        x000_revs_xx00_added_0_copies         eac3045b4fdd 51d4ae7f1290 :   1421 revs,   0.010019 s,   0.010443 s,  +0.000424 s, \u00d7 1.0423,     7 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x_copies         e2063d266acd 6081d72689dc :   1533 revs,   0.015602 s,   0.015697 s,  +0.000095 s, \u00d7 1.0061,    10 \u00b5s\/rev\nnetbeans        x000_revs_x000_added_x000_copies      ff453e9fee32 411350406ec2 :   5750 revs,   0.058759 s,   0.063528 s,  +0.004769 s, \u00d7 1.0812,    11 \u00b5s\/rev\nnetbeans        x0000_revs_xx000_added_x000_copies    588c2d1ced70 1aad62e59ddd :  66949 revs,   0.491550 s,   0.545515 s,  +0.053965 s, \u00d7 1.1098,     8 \u00b5s\/rev\nmozilla-central x_revs_x_added_0_copies               3697f962bb7b 7015fcdd43a2 :      2 revs,   0.000087 s,   0.000089 s,  +0.000002 s, \u00d7 1.0230,    44 \u00b5s\/rev\nmozilla-central x_revs_x000_added_0_copies            dd390860c6c9 40d0c5bed75d :      8 revs,   0.000268 s,   0.000265 s,  -0.000003 s, \u00d7 0.9888,    33 \u00b5s\/rev\nmozilla-central x_revs_x_added_x_copies               8d198483ae3b 14207ffc2b2f :      9 revs,   0.000181 s,   0.000381 s,  +0.000200 s, \u00d7 2.1050,    42 \u00b5s\/rev\nmozilla-central x_revs_x00_added_x_copies             98cbc58cc6bc 446a150332c3 :      7 revs,   0.000661 s,   0.000672 s,  +0.000011 s, \u00d7 1.0166,    96 \u00b5s\/rev\nmozilla-central x_revs_x000_added_x000_copies         3c684b4b8f68 0a5e72d1b479 :      3 revs,   0.003256 s,   0.003497 s,  +0.000241 s, \u00d7 1.0740,  1165 \u00b5s\/rev\nmozilla-central x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.066749 s,   0.073204 s,  +0.006455 s, \u00d7 1.0967, 12200 \u00b5s\/rev\nmozilla-central x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006462 s,   0.006482 s,  +0.000020 s, \u00d7 1.0031,     4 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.004919 s,   0.005066 s,  +0.000147 s, \u00d7 1.0299,   123 \u00b5s\/rev\nmozilla-central x000_revs_x000_added_x000_copies      7c97034feb78 4407bd0c6330 :   7839 revs,   0.062421 s,   0.065707 s,  +0.003286 s, \u00d7 1.0526,     8 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.026633 s,   0.026800 s,  +0.000167 s, \u00d7 1.0063,    43 \u00b5s\/rev\nmozilla-central x0000_revs_xx000_added_x000_copies    f78c615a656c 96a38b690156 :  30263 revs,   0.197792 s,   0.203856 s,  +0.006064 s, \u00d7 1.0307,     6 \u00b5s\/rev\nmozilla-central x00000_revs_x0000_added_x0000_copies  6832ae71433c 4c222a1d9a00 : 153721 revs,   1.259970 s,   1.293394 s,  +0.033424 s, \u00d7 1.0265,     8 \u00b5s\/rev\nmozilla-central x00000_revs_x00000_added_x000_copies  76caed42cf7c 1daa622bbe42 : 204976 revs,   1.689184 s,   1.698239 s,  +0.009055 s, \u00d7 1.0054,     8 \u00b5s\/rev\nmozilla-try     x_revs_x_added_0_copies               aaf6dde0deb8 9790f499805a :      2 revs,   0.000865 s,   0.000875 s,  +0.000010 s, \u00d7 1.0116,   437 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_0_copies            d8d0222927b4 5bb8ce8c7450 :      2 revs,   0.000893 s,   0.000891 s,  -0.000002 s, \u00d7 0.9978,   445 \u00b5s\/rev\nmozilla-try     x_revs_x_added_x_copies               092fcca11bdb 936255a0384a :      4 revs,   0.000172 s,   0.000292 s,  +0.000120 s, \u00d7 1.6977,    73 \u00b5s\/rev\nmozilla-try     x_revs_x00_added_x_copies             b53d2fadbdb5 017afae788ec :      2 revs,   0.001159 s,   0.003939 s,  +0.002780 s, \u00d7 3.3986,  1969 \u00b5s\/rev\nmozilla-try     x_revs_x000_added_x000_copies         20408ad61ce5 6f0ee96e21ad :      1 revs,   0.031621 s,   0.033027 s,  +0.001406 s, \u00d7 1.0445, 33027 \u00b5s\/rev\nmozilla-try     x_revs_x0000_added_x0000_copies       effb563bb7e5 c07a39dc4e80 :      6 revs,   0.068571 s,   0.073703 s,  +0.005132 s, \u00d7 1.0748, 12283 \u00b5s\/rev\nmozilla-try     x000_revs_xx00_added_0_copies         6100d773079a 04a55431795e :   1593 revs,   0.006452 s,   0.006469 s,  +0.000017 s, \u00d7 1.0026,     4 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x_copies         9f17a6fc04f9 2d37b966abed :     41 revs,   0.005443 s,   0.005278 s,  -0.000165 s, \u00d7 0.9697,   128 \u00b5s\/rev\nmozilla-try     x000_revs_x000_added_x000_copies      1346fd0130e4 4c65cbdabc1f :   6657 revs,   0.063180 s,   0.064995 s,  +0.001815 s, \u00d7 1.0287,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_0_copies           63519bfd42ee a36a2a865d92 :  40314 revs,   0.293564 s,   0.301041 s,  +0.007477 s, \u00d7 1.0255,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_x_added_x_copies           9fe69ff0762d bcabf2a78927 :  38690 revs,   0.286595 s,   0.285575 s,  -0.001020 s, \u00d7 0.9964,     7 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x_copies       156f6e2674f2 4d0f2c178e66 :   8598 revs,   0.083256 s,   0.085597 s,  +0.002341 s, \u00d7 1.0281,     9 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_0_copies       9eec5917337d 67118cc6dcad :    615 revs,   0.027282 s,   0.027118 s,  -0.000164 s, \u00d7 0.9940,    44 \u00b5s\/rev\nmozilla-try     x0000_revs_xx000_added_x000_copies    89294cd501d9 7ccb2fc7ccb5 :  97052 revs,   1.343373 s,   2.119204 s,  +0.775831 s, \u00d7 1.5775,    21 \u00b5s\/rev\nmozilla-try     x0000_revs_x0000_added_x0000_copies   e928c65095ed e951f4ad123a :  52031 revs,   0.665737 s,   0.701479 s,  +0.035742 s, \u00d7 1.0537,    13 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_0_copies          6a320851d377 1ebb79acd503 : 363753 revs,   5.138169 s,   4.482399 s,  -0.655770 s, \u00d7 0.8724,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_0_copies     dc8a3ca7010e d16fde900c9c :  34414 revs,   0.573276 s,   0.574082 s,  +0.000806 s, \u00d7 1.0014,    16 \u00b5s\/rev\nmozilla-try     x00000_revs_x_added_x_copies          5173c4b6f97c 95d83ee7242d : 362229 revs,   5.127809 s,   4.480366 s,  -0.647443 s, \u00d7 0.8737,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x000_added_x_copies       9126823d0e9c ca82787bb23c : 359344 revs,   4.971136 s,   4.369070 s,  -0.602066 s, \u00d7 0.8789,    12 \u00b5s\/rev\nmozilla-try     x00000_revs_x0000_added_x0000_copies  8d3fafa80d4b eb884023b810 : 192665 revs,   1.741678 s,   1.592506 s,  -0.149172 s, \u00d7 0.9144,     8 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 228985 revs,  40.314822 s,  87.824489 s, +47.509667 s, \u00d7 2.1785,   383 \u00b5s\/rev\nmozilla-try     x00000_revs_x00000_added_x000_copies  9b2a99adc05e 8e29777b48e6 : 382065 revs,  20.048029 s,  43.304637 s, +23.256608 s, \u00d7 2.1600,   113 \u00b5s\/rev\nprivate                                                                         : 459513 revs,  37.179470 s,  33.853687 s,  -3.325783 s, \u00d7 0.9105,    73 \u00b5s\/rev","testPlan":"","lineCount":"39","dependsOn":["9643"],"reviewers":["pulkit","Alphare"],"ccs":["pulkit","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146325","dateCreated":"1610119570","dateModified":"1610119570"},{"type":"update","diffId":"24641","author":"baymax","id":"146324","dateCreated":"1610119570","dateModified":"1610119570"},{"type":"accept","author":"Alphare","id":"146265","dateCreated":"1610111716","dateModified":"1610111716"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146030","dateCreated":"1609856255","dateModified":"1609856255"},{"type":"update","diffId":"24600","author":"baymax","id":"146029","dateCreated":"1609856255","dateModified":"1609856255"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145973","dateCreated":"1609836767","dateModified":"1609836767"},{"type":"update","diffId":"24578","author":"baymax","id":"145972","dateCreated":"1609836767","dateModified":"1609836767"},{"type":"accept","author":"pulkit","id":"145714","dateCreated":"1609143445","dateModified":"1609143445"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145653","dateCreated":"1608713416","dateModified":"1608713416"},{"type":"update","diffId":"24508","author":"baymax","id":"145652","dateCreated":"1608713416","dateModified":"1608713416"},{"type":"inline","comment":"moved in the right changesets, thanks.","replyTo":"145595","isNewFile":"1","line":"582","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24468","author":"marmoute","id":"145627","dateCreated":"1608689747","dateModified":"1608689747"},{"type":"inline","comment":"done thanks for pointing it out.","replyTo":"145594","isNewFile":"1","line":"26","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24468","author":"marmoute","id":"145626","dateCreated":"1608689747","dateModified":"1608689747"},{"type":"update","diffId":"24483","author":"marmoute","id":"145610","dateCreated":"1608689500","dateModified":"1608689500"},{"type":"inline","comment":"Unrelated change.","replyTo":null,"isNewFile":"1","line":"582","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24468","author":"pulkit","id":"145595","dateCreated":"1608646410","dateModified":"1608646410"},{"type":"inline","comment":"needs some documentation love.","replyTo":null,"isNewFile":"1","line":"26","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24468","author":"pulkit","id":"145594","dateCreated":"1608646410","dateModified":"1608646410"},{"type":"update","diffId":"24468","author":"marmoute","id":"145429","dateCreated":"1608589697","dateModified":"1608589697"}],"dateCreated":"1608589697","dateModified":"1610119570","status":"Accepted"},{"id":"9643","callsign":"HG","title":"copies-rust: add methods to build and update CopySource","author":"marmoute","summary":"Having explicit method with clear semantic help to clarify the code and prepare\nan update to the underlying documentation without too much disruption.","testPlan":"","lineCount":"125","dependsOn":["9657"],"reviewers":["pulkit","Alphare"],"ccs":["pulkit","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146323","dateCreated":"1610119565","dateModified":"1610119565"},{"type":"update","diffId":"24640","author":"baymax","id":"146322","dateCreated":"1610119565","dateModified":"1610119565"},{"type":"accept","author":"Alphare","id":"146258","dateCreated":"1610104523","dateModified":"1610104523"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146028","dateCreated":"1609856254","dateModified":"1609856254"},{"type":"update","diffId":"24599","author":"baymax","id":"146027","dateCreated":"1609856254","dateModified":"1609856254"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145971","dateCreated":"1609836762","dateModified":"1609836762"},{"type":"update","diffId":"24577","author":"baymax","id":"145970","dateCreated":"1609836762","dateModified":"1609836762"},{"type":"accept","author":"pulkit","id":"145712","dateCreated":"1609143401","dateModified":"1609143401"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145651","dateCreated":"1608713413","dateModified":"1608713413"},{"type":"update","diffId":"24507","author":"baymax","id":"145650","dateCreated":"1608713413","dateModified":"1608713413"},{"type":"inline","comment":"Good catch ! I forgot this was there. Updated version pushed","replyTo":"145591","isNewFile":"1","line":"687","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24467","author":"marmoute","id":"145624","dateCreated":"1608689732","dateModified":"1608689732"},{"type":"update","diffId":"24482","author":"marmoute","id":"145606","dateCreated":"1608689495","dateModified":"1608689495"},{"type":"inline","comment":"This too looks like an unrelated change as far as this patch is concerned.","replyTo":null,"isNewFile":"1","line":"711","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24467","author":"pulkit","id":"145592","dateCreated":"1608646211","dateModified":"1608646211"},{"type":"inline","comment":"Seems like an unrelated change that should be in a different patch.","replyTo":null,"isNewFile":"1","line":"687","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24467","author":"pulkit","id":"145591","dateCreated":"1608646211","dateModified":"1608646211"},{"type":"update","diffId":"24467","author":"marmoute","id":"145421","dateCreated":"1608589692","dateModified":"1608589692"}],"dateCreated":"1608589692","dateModified":"1610119565","status":"Accepted"},{"id":"9657","callsign":"HG","title":"copies-rust: fix reverted argument when merging tiny minor or major","author":"marmoute","summary":"The argument where not passed in the right other. This is not caught by the test\n(yet) because it is a sub case of a special case. Am I adding this to my list of\nthings to test. Using test directly in Rust would be appropriate here. However\nwe don't have the ability to test this code that way yet, and I am focussing on\nother part of that work right now.","testPlan":"","lineCount":"6","dependsOn":["9642"],"reviewers":["SimonSapin","Alphare"],"ccs":["SimonSapin","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146321","dateCreated":"1610119561","dateModified":"1610119561"},{"type":"update","diffId":"24639","author":"baymax","id":"146320","dateCreated":"1610119561","dateModified":"1610119561"},{"type":"accept","author":"Alphare","id":"146257","dateCreated":"1610104421","dateModified":"1610104421"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146026","dateCreated":"1609856252","dateModified":"1609856252"},{"type":"update","diffId":"24598","author":"baymax","id":"146025","dateCreated":"1609856252","dateModified":"1609856252"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145969","dateCreated":"1609836759","dateModified":"1609836759"},{"type":"update","diffId":"24576","author":"baymax","id":"145968","dateCreated":"1609836759","dateModified":"1609836759"},{"type":"comment","comment":"This makes the `else if major.len() * 2 < minor.len()` block the same as `else if minor.len() * 2 < major.len()` block above but with major and minor swapped, as it should be.","author":"SimonSapin","id":"145769","dateCreated":"1609162684","dateModified":"1609162684"},{"type":"accept","author":"SimonSapin","id":"145768","dateCreated":"1609162684","dateModified":"1609162684"},{"type":"update","diffId":"24481","author":"marmoute","id":"145599","dateCreated":"1608689490","dateModified":"1608689490"}],"dateCreated":"1608689490","dateModified":"1610119561","status":"Needs Review"},{"id":"9642","callsign":"HG","title":"copies-rust: rename TimeStampedPathCopy to CopySource","author":"marmoute","summary":"Same rational as the previous changesets. CopySource is a clear descriptive name\nthat does not depends on an implementation details that we are about to the\nchange.","testPlan":"","lineCount":"24","dependsOn":["9641"],"reviewers":["pulkit","Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146319","dateCreated":"1610119557","dateModified":"1610119557"},{"type":"update","diffId":"24638","author":"baymax","id":"146318","dateCreated":"1610119557","dateModified":"1610119557"},{"type":"accept","author":"Alphare","id":"146256","dateCreated":"1610104372","dateModified":"1610104372"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146024","dateCreated":"1609856251","dateModified":"1609856251"},{"type":"update","diffId":"24597","author":"baymax","id":"146023","dateCreated":"1609856251","dateModified":"1609856251"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145967","dateCreated":"1609836754","dateModified":"1609836754"},{"type":"update","diffId":"24575","author":"baymax","id":"145966","dateCreated":"1609836754","dateModified":"1609836754"},{"type":"accept","author":"pulkit","id":"145588","dateCreated":"1608645971","dateModified":"1608645971"},{"type":"update","diffId":"24466","author":"marmoute","id":"145413","dateCreated":"1608589688","dateModified":"1608589688"}],"dateCreated":"1608589688","dateModified":"1610119557","status":"Accepted"},{"id":"9641","callsign":"HG","title":"copies-rust: rename TimeStampedPathCopies to InternalPathCopies","author":"marmoute","summary":"We are looking into moving away from TimeStampedPathCopy (that use is_ancestors\ncall to detect overwrite) in favor of an approach that does not requires\nis_ancestors calls. Yet we will still need an internal representation that\ndiffers from the returned result.\n\nSo we call it \"InternalPathCopies\" which is generic but clear.","testPlan":"","lineCount":"30","dependsOn":["9613"],"reviewers":["pulkit","Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146317","dateCreated":"1610119554","dateModified":"1610119554"},{"type":"update","diffId":"24637","author":"baymax","id":"146316","dateCreated":"1610119554","dateModified":"1610119554"},{"type":"accept","author":"Alphare","id":"146255","dateCreated":"1610104245","dateModified":"1610104245"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146022","dateCreated":"1609856250","dateModified":"1609856250"},{"type":"update","diffId":"24596","author":"baymax","id":"146021","dateCreated":"1609856250","dateModified":"1609856250"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145965","dateCreated":"1609836751","dateModified":"1609836751"},{"type":"update","diffId":"24574","author":"baymax","id":"145964","dateCreated":"1609836751","dateModified":"1609836751"},{"type":"accept","author":"pulkit","id":"145586","dateCreated":"1608645935","dateModified":"1608645935"},{"type":"update","diffId":"24465","author":"marmoute","id":"145405","dateCreated":"1608589683","dateModified":"1608589683"}],"dateCreated":"1608589683","dateModified":"1610119554","status":"Accepted"},{"id":"9613","callsign":"HG","title":"copies: detect case when a merge decision overwrite previous data","author":"marmoute","summary":"We now detect and record when a merge case required special logic (eg: thing\nthat append during the merge, ambiguity leading to picking p1 data, etc) and we\nexplicitly mark the result as superseding the previous data.\n\nThis fixes the family of test we previously added.","testPlan":"","lineCount":"241","dependsOn":["9612"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146315","dateCreated":"1610119513","dateModified":"1610119513"},{"type":"update","diffId":"24636","author":"baymax","id":"146314","dateCreated":"1610119513","dateModified":"1610119513"},{"type":"inline","comment":"Please add a small mention of the override in the docstring","replyTo":null,"isNewFile":"1","line":"768","lineLength":"0","path":"rust\/hg-core\/src\/copy_tracing.rs","diffId":"24595","author":"Alphare","id":"146254","dateCreated":"1610104228","dateModified":"1610104228"},{"type":"inline","comment":"typo","replyTo":null,"isNewFile":"1","line":"493","lineLength":"0","path":"mercurial\/copies.py","diffId":"24595","author":"Alphare","id":"146253","dateCreated":"1610104228","dateModified":"1610104228"},{"type":"accept","author":"Alphare","id":"146252","dateCreated":"1610104228","dateModified":"1610104228"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146020","dateCreated":"1609855325","dateModified":"1609855325"},{"type":"update","diffId":"24595","author":"baymax","id":"146019","dateCreated":"1609855325","dateModified":"1609855325"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145961","dateCreated":"1609835895","dateModified":"1609835895"},{"type":"update","diffId":"24572","author":"baymax","id":"145960","dateCreated":"1609835895","dateModified":"1609835895"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145356","dateCreated":"1608537628","dateModified":"1608537628"},{"type":"update","diffId":"24456","author":"baymax","id":"145355","dateCreated":"1608537628","dateModified":"1608537628"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145172","dateCreated":"1608303303","dateModified":"1608303303"},{"type":"update","diffId":"24418","author":"baymax","id":"145171","dateCreated":"1608303303","dateModified":"1608303303"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145156","dateCreated":"1608301922","dateModified":"1608301922"},{"type":"update","diffId":"24410","author":"baymax","id":"145155","dateCreated":"1608301922","dateModified":"1608301922"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145138","dateCreated":"1608300730","dateModified":"1608300730"},{"type":"update","diffId":"24403","author":"baymax","id":"145137","dateCreated":"1608300730","dateModified":"1608300730"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145022","dateCreated":"1608239058","dateModified":"1608239058"},{"type":"update","diffId":"24376","author":"baymax","id":"145021","dateCreated":"1608239058","dateModified":"1608239058"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"144623","dateCreated":"1608050635","dateModified":"1608050635"},{"type":"update","diffId":"24285","author":"baymax","id":"144622","dateCreated":"1608050635","dateModified":"1608050635"},{"type":"update","diffId":"24283","author":"marmoute","id":"144601","dateCreated":"1608023269","dateModified":"1608023269"}],"dateCreated":"1608023269","dateModified":"1610119513","status":"Needs Review"},{"id":"9612","callsign":"HG","title":"copies: rearrange all value comparison conditional","author":"marmoute","summary":"To properly handle the newly tested case (chaining of merges) we will need to\ndetect more accurately when an actualy merging of the copy information (and\nsuperseed the two existing data). Before starting to do so, we need to\nreorganise the values comparison to introduce different conditional branches\nwhen such actual merging is needed\/detected.\n\nTo avoid mixing too many change in this complicated code, we do the\nreorganisation before adding the \"overwrite detection\" logic in the next\nchangesets.","testPlan":"","lineCount":"128","dependsOn":["9611"],"reviewers":["Alphare"],"ccs":["Alphare","mercurial-patches"],"actions":[{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146313","dateCreated":"1610119512","dateModified":"1610119512"},{"type":"update","diffId":"24635","author":"baymax","id":"146311","dateCreated":"1610119512","dateModified":"1610119512"},{"type":"comment","comment":">>! In D9612#146250, @Alphare wrote:\n> Balancing both algorithms in my head is not easy, but this looks fine, of course as long as the next patch does something more useful. :P\n> Your commit message may be missing a word or two, if you want to take a look at it.\n\nI did an extra pass on the commit message.","author":"marmoute","id":"146299","dateCreated":"1610114543","dateModified":"1610114543"},{"type":"comment","comment":"Balancing both algorithms in my head is not easy, but this looks fine, of course as long as the next patch does something more useful. :P\nYour commit message may be missing a word or two, if you want to take a look at it.","author":"Alphare","id":"146250","dateCreated":"1610102709","dateModified":"1610102709"},{"type":"accept","author":"Alphare","id":"146249","dateCreated":"1610102709","dateModified":"1610102709"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146018","dateCreated":"1609855321","dateModified":"1609855321"},{"type":"update","diffId":"24594","author":"baymax","id":"146017","dateCreated":"1609855321","dateModified":"1609855321"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145959","dateCreated":"1609835890","dateModified":"1609835890"},{"type":"update","diffId":"24571","author":"baymax","id":"145958","dateCreated":"1609835890","dateModified":"1609835890"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145354","dateCreated":"1608537626","dateModified":"1608537626"},{"type":"update","diffId":"24455","author":"baymax","id":"145353","dateCreated":"1608537626","dateModified":"1608537626"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145170","dateCreated":"1608303299","dateModified":"1608303299"},{"type":"update","diffId":"24417","author":"baymax","id":"145169","dateCreated":"1608303299","dateModified":"1608303299"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145154","dateCreated":"1608301920","dateModified":"1608301920"},{"type":"update","diffId":"24409","author":"baymax","id":"145153","dateCreated":"1608301920","dateModified":"1608301920"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145136","dateCreated":"1608300728","dateModified":"1608300728"},{"type":"update","diffId":"24402","author":"baymax","id":"145135","dateCreated":"1608300728","dateModified":"1608300728"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145020","dateCreated":"1608239054","dateModified":"1608239054"},{"type":"update","diffId":"24375","author":"baymax","id":"145019","dateCreated":"1608239054","dateModified":"1608239054"},{"type":"update","diffId":"24282","author":"marmoute","id":"144593","dateCreated":"1608023264","dateModified":"1608023264"}],"dateCreated":"1608023264","dateModified":"1610119512","status":"Needs Review"},{"id":"9611","callsign":"HG","title":"copies-test: add test chaining multiple merge","author":"marmoute","summary":"Right now, the copy tracing logic take the right decision for merges, but it\ndoes not keep track of the right information about these decision and can fall\ninto later traps. We start with highlighting this possibility by adding new\ntests, and we will fix them later.\n\nCheck the inline test documentation for details.","testPlan":"","lineCount":"172","dependsOn":["9610"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"146247","dateCreated":"1610101620","dateModified":"1610101620"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146016","dateCreated":"1609855318","dateModified":"1609855318"},{"type":"update","diffId":"24593","author":"baymax","id":"146015","dateCreated":"1609855318","dateModified":"1609855318"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145957","dateCreated":"1609835887","dateModified":"1609835887"},{"type":"update","diffId":"24570","author":"baymax","id":"145956","dateCreated":"1609835887","dateModified":"1609835887"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145352","dateCreated":"1608537624","dateModified":"1608537624"},{"type":"update","diffId":"24454","author":"baymax","id":"145351","dateCreated":"1608537624","dateModified":"1608537624"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145168","dateCreated":"1608303296","dateModified":"1608303296"},{"type":"update","diffId":"24416","author":"baymax","id":"145167","dateCreated":"1608303296","dateModified":"1608303296"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145152","dateCreated":"1608301919","dateModified":"1608301919"},{"type":"update","diffId":"24408","author":"baymax","id":"145151","dateCreated":"1608301919","dateModified":"1608301919"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145134","dateCreated":"1608300726","dateModified":"1608300726"},{"type":"update","diffId":"24401","author":"baymax","id":"145133","dateCreated":"1608300726","dateModified":"1608300726"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145018","dateCreated":"1608239050","dateModified":"1608239050"},{"type":"update","diffId":"24374","author":"baymax","id":"145017","dateCreated":"1608239050","dateModified":"1608239050"},{"type":"update","diffId":"24281","author":"marmoute","id":"144585","dateCreated":"1608023260","dateModified":"1608023260"}],"dateCreated":"1608023260","dateModified":"1610119510","status":"Needs Review"},{"id":"9610","callsign":"HG","title":"copies-test: add test chaining multiple merge","author":"marmoute","summary":"Right now, the copy tracing logic take the right decision for merges, but it\ndoes not keep track of the right information about these decision and can fall\ninto later traps. We start with highlighting this possibility by adding new\ntests, and we will fix them later.\n\nCheck the inline test documentation for details.","testPlan":"","lineCount":"167","dependsOn":["9609"],"reviewers":["Alphare"],"ccs":["mercurial-patches"],"actions":[{"type":"accept","author":"Alphare","id":"146246","dateCreated":"1610101339","dateModified":"1610101339"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146014","dateCreated":"1609855315","dateModified":"1609855315"},{"type":"update","diffId":"24592","author":"baymax","id":"146013","dateCreated":"1609855315","dateModified":"1609855315"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145955","dateCreated":"1609835883","dateModified":"1609835883"},{"type":"update","diffId":"24569","author":"baymax","id":"145954","dateCreated":"1609835883","dateModified":"1609835883"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145350","dateCreated":"1608537622","dateModified":"1608537622"},{"type":"update","diffId":"24453","author":"baymax","id":"145349","dateCreated":"1608537622","dateModified":"1608537622"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145166","dateCreated":"1608303293","dateModified":"1608303293"},{"type":"update","diffId":"24415","author":"baymax","id":"145165","dateCreated":"1608303293","dateModified":"1608303293"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145150","dateCreated":"1608301917","dateModified":"1608301917"},{"type":"update","diffId":"24407","author":"baymax","id":"145149","dateCreated":"1608301917","dateModified":"1608301917"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145132","dateCreated":"1608300725","dateModified":"1608300725"},{"type":"update","diffId":"24400","author":"baymax","id":"145131","dateCreated":"1608300725","dateModified":"1608300725"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145016","dateCreated":"1608239046","dateModified":"1608239046"},{"type":"update","diffId":"24373","author":"baymax","id":"145015","dateCreated":"1608239046","dateModified":"1608239046"},{"type":"update","diffId":"24280","author":"marmoute","id":"144577","dateCreated":"1608023255","dateModified":"1608023255"}],"dateCreated":"1608023255","dateModified":"1610119509","status":"Needs Review"},{"id":"9609","callsign":"HG","title":"copies-test: add test chaining multiple merge","author":"marmoute","summary":"Right now, the copy tracing logic take the right decision for merges, but it\ndoes not keep track of the right information about these decision and can fall\ninto later traps. We start with highlighting this possibility by adding new\ntests, and we will fix them later.\n\nCheck the inline test documentation for details.","testPlan":"","lineCount":"196","dependsOn":["9587"],"reviewers":["Alphare"],"ccs":["nikkireed1122","ulrickaka","pulkit","mercurial-patches"],"actions":[{"type":"comment","comment":"[[ https:\/\/proseogroupbuy.com\/lucidchart\/ | Lucidchart Group Buy ]]\nis the best online graphing tool that makes drawing charts quick and easy. Quick flowcharts, company graphs, wireframes, UML, mind","author":"nikkireed1122","id":"146074","dateCreated":"1609874328","dateModified":"1609874328"},{"type":"comment","comment":"[[ https:\/\/www.buymoviejackets.com\/product-category\/new-motorcycle-leather-jackets | Leather Motorcycle Jackets for Women ]]\nFind stylish motorcycle jackets for women at Wilsons Leather. Our collection feature quality leather moto jackets in a variety of colors and styles","author":"ulrickaka","id":"146072","dateCreated":"1609873565","dateModified":"1609873565"},{"type":"accept","author":"Alphare","id":"146068","dateCreated":"1609865230","dateModified":"1609865230"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146012","dateCreated":"1609855312","dateModified":"1609855312"},{"type":"update","diffId":"24591","author":"baymax","id":"146011","dateCreated":"1609855312","dateModified":"1609855312"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145953","dateCreated":"1609835879","dateModified":"1609835879"},{"type":"update","diffId":"24568","author":"baymax","id":"145952","dateCreated":"1609835879","dateModified":"1609835879"},{"type":"inline","comment":"This comment is relevant to the conversation we are having.","replyTo":null,"isNewFile":"1","line":"1375","lineLength":"0","path":"tests\/test-copies-chain-merge.t","diffId":"24452","author":"marmoute","id":"145951","dateCreated":"1609835333","dateModified":"1609835333"},{"type":"inline","comment":"The logic behind the filelog output is not \"buggy\" it simply use a different (more arbitrary) tie breaking mechanism that is stable regardless of the p1\/p2 order. The behavior of the changeset centric algorithm is more \"predictable\", a hence a bit better in my opinion, however, the filelog one have been around since for-ever, so lets not touch it.","replyTo":"145947","isNewFile":"1","line":"1937","lineLength":"0","path":"tests\/test-copies-chain-merge.t","diffId":"24452","author":"marmoute","id":"145949","dateCreated":"1609833494","dateModified":"1609833494"},{"type":"inline","comment":"I thought we can use `known-bad-output` for expected buggy output too.","replyTo":"145945","isNewFile":"1","line":"1937","lineLength":"0","path":"tests\/test-copies-chain-merge.t","diffId":"24452","author":"pulkit","id":"145947","dateCreated":"1609833201","dateModified":"1609833201"},{"type":"inline","comment":"Why should they be? This is the expected output for the filelog based logic.","replyTo":"145721","isNewFile":"1","line":"1937","lineLength":"0","path":"tests\/test-copies-chain-merge.t","diffId":"24452","author":"marmoute","id":"145945","dateCreated":"1609833022","dateModified":"1609833022"},{"type":"inline","comment":"Shouldn't this and similar one above too be marked as `known-bad-output`?","replyTo":null,"isNewFile":"1","line":"1937","lineLength":"0","path":"tests\/test-copies-chain-merge.t","diffId":"24452","author":"pulkit","id":"145721","dateCreated":"1609144344","dateModified":"1609144344"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145348","dateCreated":"1608537621","dateModified":"1608537621"},{"type":"update","diffId":"24452","author":"baymax","id":"145347","dateCreated":"1608537621","dateModified":"1608537621"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145164","dateCreated":"1608303290","dateModified":"1608303290"},{"type":"update","diffId":"24414","author":"baymax","id":"145163","dateCreated":"1608303290","dateModified":"1608303290"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145148","dateCreated":"1608301916","dateModified":"1608301916"},{"type":"update","diffId":"24406","author":"baymax","id":"145147","dateCreated":"1608301916","dateModified":"1608301916"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145130","dateCreated":"1608300724","dateModified":"1608300724"},{"type":"update","diffId":"24399","author":"baymax","id":"145129","dateCreated":"1608300724","dateModified":"1608300724"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"145014","dateCreated":"1608239042","dateModified":"1608239042"},{"type":"update","diffId":"24372","author":"baymax","id":"145013","dateCreated":"1608239042","dateModified":"1608239042"},{"type":"update","diffId":"24279","author":"marmoute","id":"144569","dateCreated":"1608023250","dateModified":"1608023250"}],"dateCreated":"1608023250","dateModified":"1610119508","status":"Needs Review"},{"id":"9571","callsign":"HG","title":"debugsharesafe: recommend from `debugupgraderepo` and `help -e share -v`","author":"pulkit","summary":"Recommending one debug command from another one sounds fine to me.\n\nAlso documentation about share-safe in `hg help -e share -v` was lacking correct\ndescription on how upgrade existing shares. This fixes that and also start\nmentioning about debugsharesafe.","testPlan":"","lineCount":"24","dependsOn":["9570"],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"plan-changes","author":"pulkit","id":"146083","dateCreated":"1609935160","dateModified":"1609935160"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146081","dateCreated":"1609934020","dateModified":"1609934020"},{"type":"update","diffId":"24611","author":"baymax","id":"146080","dateCreated":"1609934020","dateModified":"1609934020"},{"type":"update","diffId":"24195","author":"pulkit","id":"144155","dateCreated":"1607770008","dateModified":"1607770008"}],"dateCreated":"1607770008","dateModified":"1609935160","status":"Changes Planned"},{"id":"9570","callsign":"HG","title":"debugcommands: introduce command to upgrade\/downgrade shares","author":"pulkit","summary":"In past few months, we have developed functionality to share requirements and\nconfigs of share-source and a way to upgrade repository from old format to\nshare-safe format using `debugupgraderepo` command.\n\nHowever there is still no way to upgrade the shares as `debugupgraderepo` does\nnot support upgrading that.\n\nHaving share-safe rolled out in existing setup is quite important and hence we\nneed a way to upgrade existing shares once share-source upgrades.\n\nThis patch introduces a new debug command `debugsharesafe` which can be used to\nupgrade or downgrade shares.\n\nFunctionality to upgrade shares to use the new method is the last thing left in\nthe whole work.","testPlan":"","lineCount":"136","dependsOn":[],"reviewers":[],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"plan-changes","author":"pulkit","id":"146082","dateCreated":"1609935145","dateModified":"1609935145"},{"type":"comment","comment":":white_check_mark: refresh by Heptapod after a successful CI run (:octopus: :green_heart:)","author":"baymax","id":"146079","dateCreated":"1609934019","dateModified":"1609934019"},{"type":"update","diffId":"24610","author":"baymax","id":"146078","dateCreated":"1609934019","dateModified":"1609934019"},{"type":"comment","comment":">>! In D9570#145047, @pulkit wrote:\n>>>! In D9570#145046, @marmoute wrote:\n>> should we simply teach `hg debugupgraderepo` to do this type of upgrade on shares? I am not comfortable with adding  new updata\/downgradfe command for specific requirements as it would become a jungle quite quickly.\n> \n> `hg debugupgraderepo` does not support upgrading shares. It will require some good amount of work to have `hg debugupgraderepo` support shares and hence I didn't go that way.\n\nDo you think we could we have this as some early branching in debugupgraderepo ?","author":"marmoute","id":"145545","dateCreated":"1608625824","dateModified":"1608625824"},{"type":"comment","comment":">>! In D9570#145046, @marmoute wrote:\n> should we simply teach `hg debugupgraderepo` to do this type of upgrade on shares? I am not comfortable with adding  new updata\/downgradfe command for specific requirements as it would become a jungle quite quickly.\n\n`hg debugupgraderepo` does not support upgrading shares. It will require some good amount of work to have `hg debugupgraderepo` support shares and hence I didn't go that way.","author":"pulkit","id":"145047","dateCreated":"1608294250","dateModified":"1608294250"},{"type":"comment","comment":"should we simply teach `hg debugupgraderepo` to do this type of upgrade on shares? I am not comfortable with adding  new updata\/downgradfe command for specific requirements as it would become a jungle quite quickly.","author":"marmoute","id":"145046","dateCreated":"1608292808","dateModified":"1608292808"},{"type":"update","diffId":"24194","author":"pulkit","id":"144147","dateCreated":"1607770003","dateModified":"1607770003"}],"dateCreated":"1607770003","dateModified":"1609935145","status":"Changes Planned"},{"id":"9274","callsign":"HG","title":"internals: start to document how .hg\/ works","author":"indygreg","summary":"This commit adds internals documentation that starts to document the\nfiles and semantics of the .hg\/ directory.\n\nA lot of this functionality is currently only documented via code\n(that doesn't count as documentation!). And the semantics are often wonky\nenough that it warrants documentation.\n\nI set out attempting to document the file layout for .hg\/. Along the\nway, I realized I also needed to document the semantics of lock files,\nthe path encoding of the revlog store, and how transactions work.\n\nThe documentation is missing critical information, such as a thorough\naccounting of all the random files in .hg\/ and .hg\/store and their\nformats. But perfect is the enemy of good. And some documentation\nseems strictly better than no documentation.\n\nThe transaction documentation could definitely be better. However, the\ntransaction code and transaction semantics are a hot mess and it is\nincredibly difficult to read and reason about. I think the only reasonable\nway we document and validate the documentation of transactions is by\nrefactoring the code to actually be readable and document what we learn\nalong the way.\n\nI started writing these docs several months ago, before the shared hgrc\nwork started. So the documentation is missing details about this feature\nas well. But that's an experimental feature. Hopefully we can add details\nof this feature to these docs before that feature stabilizes.","testPlan":"","lineCount":"535","dependsOn":[],"reviewers":[],"ccs":["marmoute","mharbison72","joerg.sonnenberger","mercurial-patches"],"actions":[{"type":"comment","comment":"(That patch is a bit daunting to review, maybe having each section in their own patch would help to process them in smaller piece)","author":"marmoute","id":"145580","dateCreated":"1608629821","dateModified":"1608629821"},{"type":"inline","comment":"> .hg\/hgrc is an exception here. Any others?\n\nI can't think of any writable examples, but the strip backups are maybe a read-only exception.","replyTo":"139506","isNewFile":"1","line":"5","lineLength":"0","path":"mercurial\/helptext\/internals\/repolayout.txt","diffId":"23424","author":"mharbison72","id":"139829","dateCreated":"1605159117","dateModified":"1605159117"},{"type":"inline","comment":"The inline -> external storage for revlog files should be documented as a special case here. I'm not even sure if the current logic is fully correct for that...","replyTo":null,"isNewFile":"1","line":"339","lineLength":"0","path":"mercurial\/helptext\/internals\/store-revlog.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139515","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"As discussed earlier on IRC, I think the \"cache\" file property is currently hard-wired to 0 with no interface to set it to 1?","replyTo":null,"isNewFile":"1","line":"330","lineLength":"0","path":"mercurial\/helptext\/internals\/store-revlog.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139514","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"See above.","replyTo":null,"isNewFile":"1","line":"191","lineLength":"0","path":"mercurial\/helptext\/internals\/store-revlog.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139513","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"Byte value of 0 is not possible?","replyTo":null,"isNewFile":"1","line":"131","lineLength":"0","path":"mercurial\/helptext\/internals\/store-revlog.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139512","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"using inline storage?","replyTo":null,"isNewFile":"1","line":"44","lineLength":"0","path":"mercurial\/helptext\/internals\/store-revlog.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139511","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"00manifest.i?","replyTo":null,"isNewFile":"1","line":"43","lineLength":"0","path":"mercurial\/helptext\/internals\/store-revlog.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139510","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"Mention cache and wcache as placeholders at least? Any other important items?","replyTo":null,"isNewFile":"1","line":"69","lineLength":"0","path":"mercurial\/helptext\/internals\/repolayout.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139509","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"Maybe \"unknown properties of the repository encoding\" instead of UB?","replyTo":null,"isNewFile":"1","line":"18","lineLength":"0","path":"mercurial\/helptext\/internals\/repolayout.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139508","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":"We try to read the content of the symlink? Not sure if documenting the reason for a symlink (atomic creation including content) makes sense here.","replyTo":null,"isNewFile":"1","line":"51","lineLength":"0","path":"mercurial\/helptext\/internals\/locks.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139507","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"inline","comment":".hg\/hgrc is an exception here. Any others?","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"mercurial\/helptext\/internals\/repolayout.txt","diffId":"23424","author":"joerg.sonnenberger","id":"139506","dateCreated":"1604782575","dateModified":"1604782575"},{"type":"update","diffId":"23424","author":"indygreg","id":"139497","dateCreated":"1604778173","dateModified":"1604778173"}],"dateCreated":"1604778173","dateModified":"1608629821","status":"Needs Review"},{"id":"9636","callsign":"HG","title":"bundle: add option to avoid checking further delta candidates [POC]","author":"joerg.sonnenberger","summary":"Especially when applying a clone bundle and the follow-up pull, the\ndeltas will be nearly optimal. Add a test config flag to skip any\nattempts at finding a better delta base. Test base for how this\ninteracts with parallel delta compression in addgroup.\n\nTest with a bundle of the HG repo: -2%, non-noticable size difference\nTest with a bundle of the NetBSD src repo: -18%, +10% manifest size","testPlan":"","lineCount":"30","dependsOn":[],"reviewers":["indygreg"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":">>! In D9636#145536, @joerg.sonnenberger wrote:\n> It was primarily meant to identify problem areas. The primary win here is skipping the delta finding for manifests. It seems like the problem is that we force a delta to be generated for snapshots and the target repo doesn't completely agree on when snapshots are supposed to happen. Given the size of the manifests here, the delta generation is reasonable expensive.\n\nDo you have timing about the amount of time we spend in snapshot\/semi-snapshot vs the rest of the unbundle ?","author":"marmoute","id":"145577","dateCreated":"1608627272","dateModified":"1608627272"},{"type":"comment","comment":"It was primarily meant to identify problem areas. The primary win here is skipping the delta finding for manifests. It seems like the problem is that we force a delta to be generated for snapshots and the target repo doesn't completely agree on when snapshots are supposed to happen. Given the size of the manifests here, the delta generation is reasonable expensive.","author":"joerg.sonnenberger","id":"145536","dateCreated":"1608599736","dateModified":"1608599736"},{"type":"comment","comment":"I feel like effrot would be better spend generating better bundle (or adding more delta related information in the bundle) than doing this kind of changes.","author":"marmoute","id":"145319","dateCreated":"1608421082","dateModified":"1608421082"},{"type":"comment","comment":"Some further tests show that this is indeed primarily the manifest handling. There are some peculiarities with the commit graph of this specific repository, so this likely doesn't apply to other repositories as much.","author":"joerg.sonnenberger","id":"145317","dateCreated":"1608418432","dateModified":"1608418432"},{"type":"update","diffId":"24442","author":"joerg.sonnenberger","id":"145300","dateCreated":"1608389045","dateModified":"1608389045"}],"dateCreated":"1608389045","dateModified":"1608627272","status":"Needs Review"},{"id":"6259","callsign":"HG","title":"[POC] revset: on-disk cache for children queries","author":"joerg.sonnenberger","summary":"This is a proof of concept for further discussion.","testPlan":"","lineCount":"175","dependsOn":[],"reviewers":["marmoute","baymax"],"ccs":["pulkit","mercurial-patches","marmoute","martinvonz","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"145542","dateCreated":"1608625355","dateModified":"1608625355"},{"type":"reject","author":"baymax","id":"145541","dateCreated":"1608625355","dateModified":"1608625355"},{"type":"comment","comment":"The approach used by the nodemap is probably a good way forward for transactional case. Some kind of happen only index, that get recompacked on a regular basis. Combined with an append only data file (for example, children can be stored as linked list (data file size) with a pointer to the first entry in an index file.","author":"marmoute","id":"134946","dateCreated":"1599812642","dateModified":"1599812642"},{"type":"comment","comment":"Yes, it's still a POC. I wanted to make sure that it works in the modern world, but I am still considering the idea in the context of larger changes for transactional caches.","author":"joerg.sonnenberger","id":"131111","dateCreated":"1595252777","dateModified":"1595252777"},{"type":"comment","comment":"@joerg.sonnenberger Is this still a POC? I see that you updated the code.","author":"pulkit","id":"131101","dateCreated":"1595249913","dateModified":"1595249913"},{"type":"update","diffId":"21871","author":"joerg.sonnenberger","id":"130326","dateCreated":"1594605152","dateModified":"1594605152"},{"type":"comment","comment":"This is POC, so moving out of review.","author":"marmoute","id":"126451","dateCreated":"1587571538","dateModified":"1587571538"},{"type":"reject","author":"marmoute","id":"126450","dateCreated":"1587571538","dateModified":"1587571538"},{"type":"comment","comment":"If we have one, we'll want it to be generic (so also for changelog). Do we have performance number of the time it takes to build it ?","author":"marmoute","id":"117298","dateCreated":"1579799991","dateModified":"1579799991"},{"type":"comment","comment":"Perhaps we'd want this to not be specifically for revsets? We could also write to it when we write to the changelog to keep it up to date.","author":"martinvonz","id":"91118","dateCreated":"1555507748","dateModified":"1555507748"},{"type":"comment","comment":"For the NetBSD repository, a trivial test with the new cache:\n\n```\ntime hg log -r '1000~-400' -T {node} > \/dev\/null\nreal\t0m1.898s\ntime hg log -r '1000~-400' -T {node} > \/dev\/null\nreal\t0m0.170s\ntime hg log -r '1000~-1' -T {node} > \/dev\/null\nreal\t0m0.166s\ntime hg log -r '440000~-1' -T {node} > \/dev\/null\nreal\t0m0.170s\n```\n\nFirst one includes the time to initially warmup the cache.\n\nWithout the cache:\n```\ntime hg log -r '1000~0' -T {node} > \/dev\/null\nreal\t0m0.196s\ntime hg log -r '1000~-1' -T {node} > \/dev\/null\nreal\t0m0.825s\ntime hg log -r '1000~-2' -T {node} > \/dev\/null\nreal\t0m1.288s\ntime hg log -r '1000~-400' -T {node} > \/dev\/null\nreal\t3m23.201s\ntime hg log -r '440000~-1' -T {node} > \/dev\/null\nreal\t0m0.182s\n```\n\nIn other words, building the cache is amortised by one or two queries for children early up in the tree. The cache still provides a good benefit nearer to tip.","author":"joerg.sonnenberger","id":"91110","dateCreated":"1555505679","dateModified":"1555505679"},{"type":"comment","comment":"Do you have performance numbers to share? Substantial wins would definitely pique my interest :)","author":"indygreg","id":"91066","dateCreated":"1555498467","dateModified":"1555498467"},{"type":"update","diffId":"14789","author":"joerg.sonnenberger","id":"91040","dateCreated":"1555454599","dateModified":"1555454599"}],"dateCreated":"1555454599","dateModified":"1608625355","status":"Needs Revision"},{"id":"8972","callsign":"HG","title":"[WIP] diff: add a `--tool` flag","author":"pulkit","summary":"This is a WIP because it's mostly plumbing at the moment and wanted to share it\nwith others.","testPlan":"","lineCount":"189","dependsOn":[],"reviewers":["baymax"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"145539","dateCreated":"1608625354","dateModified":"1608625354"},{"type":"reject","author":"baymax","id":"145538","dateCreated":"1608625354","dateModified":"1608625354"},{"type":"comment","comment":"Should we move this to change requested since this is WIP ?","author":"marmoute","id":"134951","dateCreated":"1599812972","dateModified":"1599812972"},{"type":"update","diffId":"22490","author":"pulkit","id":"134314","dateCreated":"1598710710","dateModified":"1598710710"}],"dateCreated":"1598710710","dateModified":"1608625354","status":"Needs Revision"},{"id":"9159","callsign":"HG","title":"[RFC] merge: stop caring about whether files are related (issue6163)","author":"martinvonz","summary":"See discussion in\nhttps:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6163. D9130 reminded me\nof this idea.","testPlan":"","lineCount":"74","dependsOn":[],"reviewers":["marmoute","pulkit"],"ccs":["pulkit","marmoute","mercurial-patches"],"actions":[{"type":"reject","author":"marmoute","id":"143218","dateCreated":"1607123050","dateModified":"1607123050"},{"type":"comment","comment":">>! In D9159#143135, @martinvonz wrote:\n>>>! In D9159#143133, @pulkit wrote:\n>> IIUC changes are planned on this one as the test case mentioned fails with this patch. Kindly correct me if I am wrong.\n> \n> Yes, I'll see if I can fix that without making things too slow. If I can't, this patch may still be an improvement since it fixes many of the more common cases and breaks a less common one.\n\nPlease note that the changesets centric code (and tests) is still in active development  on both is behavior (they are probably more bug laying around) and performance. Please refrain from sending patch in this area without coordinating with the people at Octobus doing that work. Thanks.","author":"marmoute","id":"143217","dateCreated":"1607123030","dateModified":"1607123030"},{"type":"comment","comment":">>! In D9159#143133, @pulkit wrote:\n> IIUC changes are planned on this one as the test case mentioned fails with this patch. Kindly correct me if I am wrong.\n\nYes, I'll see if I can fix that without making things too slow. If I can't, this patch may still be an improvement since it fixes many of the more common cases and breaks a less common one.","author":"martinvonz","id":"143135","dateCreated":"1607108659","dateModified":"1607108659"},{"type":"comment","comment":"IIUC changes are planned on this one as the test case mentioned fails with this patch. Kindly correct me if I am wrong.","author":"pulkit","id":"143133","dateCreated":"1607108461","dateModified":"1607108461"},{"type":"reject","author":"pulkit","id":"143132","dateCreated":"1607108461","dateModified":"1607108461"},{"type":"update","diffId":"23140","author":"martinvonz","id":"137919","dateCreated":"1602229052","dateModified":"1602229052"},{"type":"comment","comment":"test\n\n>>! In D9159#137749, @martinvonz wrote:\n>>>! In D9159#137729, @marmoute wrote:\n>> Regardless of the issue6163 question, simply dropping the tracking or removed files seems wrong and will introduces bug (eg: we can end up merging a \"dead\" file history with a fresh file history, picking the \"dead\" one). So we cannot do that.\n>> \n>> minimal description of the case I am talking about below.\n>> \n>> ```\n>> o \u2192 X should be copied from B, not A\n>> | \\\n>> o |  delete X \n>> | |\n>> o |  rename A to X\n>> | |\n>> | o rename B to X\n>> |\/\n>> o\n>> ```\n> \n> I added that test as a parent of this patch (D9171). It passed before and after this patch. Did I not write it down correctly?\n\nHmm, I must have run tests on another version of something, because the test now fails for me with this patch, which makes sense. I think I once had a check in the code merging the copy dicts from each merge parent to make it ignore copies that had been deleted (like in this test case), but it was really slow. I took a quick look but I didn't find it and it's getting late here.","author":"martinvonz","id":"137918","dateCreated":"1602228902","dateModified":"1602228902"},{"type":"update","diffId":"23123","author":"martinvonz","id":"137894","dateCreated":"1602224920","dateModified":"1602224920"},{"type":"comment","comment":">>! In D9159#137869, @marmoute wrote:\n> My previous, larger comment got lost. It contained other tests cases.\n> \n> I do not have time re-type my full comment (phabricator eating comment is very upsetting).\n\nWeird, never happened to me.\n\n> Please stop pushing this diff forward, it is broken.\n\nWell, you'll have to provide at least some proof of *what* is broken then.","author":"martinvonz","id":"137870","dateCreated":"1602194479","dateModified":"1602194479"},{"type":"comment","comment":"My previous, larger comment got lost. It contained other tests cases.\n\nI do not have time re-type my full comment (phabricator eating comment is very upsetting). Please stop pushing this diff forward, it is broken.","author":"marmoute","id":"137869","dateCreated":"1602193033","dateModified":"1602193033"},{"type":"reject","author":"marmoute","id":"137868","dateCreated":"1602193033","dateModified":"1602193033"},{"type":"comment","comment":"I've exported the current state so you can see the differences on the entire test suite, but I plan to make it configurable so it can be rolled out slowly. Maybe I'll make a copy of `test-copies-unrelated.t` then, or maybe I'll add another `#testcases follow nofollow` to the file.","author":"martinvonz","id":"137836","dateCreated":"1602178082","dateModified":"1602178082"},{"type":"plan-changes","author":"martinvonz","id":"137835","dateCreated":"1602178082","dateModified":"1602178082"},{"type":"update","diffId":"23113","author":"martinvonz","id":"137831","dateCreated":"1602177832","dateModified":"1602177832"},{"type":"update","diffId":"23111","author":"martinvonz","id":"137822","dateCreated":"1602173916","dateModified":"1602173916"},{"type":"comment","comment":">>! In D9159#137729, @marmoute wrote:\n> Regardless of the issue6163 question, simply dropping the tracking or removed files seems wrong and will introduces bug (eg: we can end up merging a \"dead\" file history with a fresh file history, picking the \"dead\" one). So we cannot do that.\n> \n> minimal description of the case I am talking about below.\n> \n> ```\n> o \u2192 X should be copied from B, not A\n> | \\\n> o |  delete X \n> | |\n> o |  rename A to X\n> | |\n> | o rename B to X\n> |\/\n> o\n> ```\n\nI added that test as a parent of this patch (D9171). It passed before and after this patch. Did I not write it down correctly?","author":"martinvonz","id":"137749","dateCreated":"1602170117","dateModified":"1602170117"},{"type":"update","diffId":"23082","author":"martinvonz","id":"137744","dateCreated":"1602170063","dateModified":"1602170063"},{"type":"comment","comment":"We would also need more code for simpler case:\n\n```\n4 \u2192 copy tracing from 1 to 4 should not list X\u2190Y \n| \\\n3 | delete Y\n|\/\n2 rename X \u2192 Y\n|\n1 \u2026\n```","author":"marmoute","id":"137731","dateCreated":"1602149158","dateModified":"1602149158"},{"type":"comment","comment":"Regardless of the issue6163 question, simply dropping the tracking or removed files seems wrong and will introduces bug (eg: we can end up merging a \"dead\" file history with a fresh file history, picking the \"dead\" one). So we cannot do that.\n\nminimal description of the case I am talking about below.\n\n```\no \u2192 X should be copied from B, not A\n| \\\no |  delete X \n| |\no |  rename A to X\n| |\n| o rename B to X\n|\/\no\n```","author":"marmoute","id":"137729","dateCreated":"1602148862","dateModified":"1602148862"},{"type":"reject","author":"marmoute","id":"137728","dateCreated":"1602148862","dateModified":"1602148862"},{"type":"update","diffId":"23064","author":"martinvonz","id":"137583","dateCreated":"1602029150","dateModified":"1602029150"}],"dateCreated":"1602029150","dateModified":"1607123050","status":"Needs Revision"},{"id":"9374","callsign":"HG","title":"bisect: add a `--rev` flag","author":"SimonSapin","summary":"This is the same as the positional argument, and can be passed more than once.","testPlan":"","lineCount":"9","dependsOn":[],"reviewers":["Alphare","martinvonz"],"ccs":["martinvonz","marmoute","mharbison72","mercurial-patches"],"actions":[{"type":"inline","comment":"nit: while you're touching this code, could you also rename this variable to `revs` to make it clear that it's a collection?","replyTo":null,"isNewFile":"1","line":"913","lineLength":"0","path":"mercurial\/commands.py","diffId":"23631","author":"martinvonz","id":"143169","dateCreated":"1607111340","dateModified":"1607111340"},{"type":"inline","comment":"I fear that this will increase the likelihood that the user runs `hg bisect -r abc123`, so could you insert a patch before this one to make sure that that is an error?","replyTo":null,"isNewFile":"1","line":"894","lineLength":"0","path":"mercurial\/commands.py","diffId":"23631","author":"martinvonz","id":"143168","dateCreated":"1607111340","dateModified":"1607111340"},{"type":"reject","author":"martinvonz","id":"143167","dateCreated":"1607111340","dateModified":"1607111340"},{"type":"inline","comment":"The addition of `--rev` is more to mirror other command that take revset as unnamed argument (eg export). I am totally fine with also making multiple revs accepted by this command.","replyTo":"141155","isNewFile":"1","line":"236","lineLength":"0","path":"tests\/test-bisect.t","diffId":"23631","author":"marmoute","id":"141680","dateCreated":"1606497871","dateModified":"1606497871"},{"type":"inline","comment":"I'm curious what other reviewers think from an API design- the good\/bad\/skip is a bool, so it feels strange to get the first revspec free, but then need an option for subsequent ones.  Can't multiple revspecs be passed in the way a list of files can be passed into file based commands?\n\nRelated: https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=5530","replyTo":null,"isNewFile":"1","line":"236","lineLength":"0","path":"tests\/test-bisect.t","diffId":"23631","author":"mharbison72","id":"141155","dateCreated":"1606282713","dateModified":"1606282713"},{"type":"accept","author":"Alphare","id":"141027","dateCreated":"1606216659","dateModified":"1606216659"},{"type":"update","diffId":"23631","author":"SimonSapin","id":"140930","dateCreated":"1606151872","dateModified":"1606151872"}],"dateCreated":"1606151872","dateModified":"1607111340","status":"Needs Revision"},{"id":"7575","callsign":"HG","title":"hg-core: vendor Facebook's configparser crate","author":"indygreg","summary":"I added a number of files from https:\/\/github.com\/facebookexperimental\/eden\nat commit b745b4421b8a8b130d2094b598cedf65655410ec. Files are unmodified from\ntheir original versions. However, the paths are different: I've put all\nfiles in the same directory. And I've removed some files we don't care about\n(such as the C++ bindings and CMake rules). Notably missing is the\nauto-generated parser.rs and the Python script to generate it. We will\nbe able to generate this file automatically at build time (unlike\nFacebook, which is constrained by not using Cargo or something).\n\nThe added files are not part of the hg-core project yet. Things will be\nincorporated in future commits.\n\nI haven't extensively audited the added code for functional correctness\nand compatibility. But I did skim it and it seems to be a highly compatible\nconfig parsing implementation. The most suspect code I found was around\nconfig file path handling. There are references to \"tupperware,\" which\nappears to be a Facebook-specific thing. We will want to clean this up\nat some point...","testPlan":"","lineCount":"2319","dependsOn":["7574"],"reviewers":["baymax"],"ccs":["mercurial-patches","marmoute","pulkit","Alphare","quark","durin42","kevincox","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"130683","dateCreated":"1594830054","dateModified":"1594830054"},{"type":"reject","author":"baymax","id":"130682","dateCreated":"1594830054","dateModified":"1594830054"},{"type":"comment","comment":"@Alphare What's your current opinion on this diff, can you mark it accepted or request change appropriatly ?","author":"marmoute","id":"124050","dateCreated":"1584659140","dateModified":"1584659140"},{"type":"comment","comment":"The C bindings need to be dropped in this patch. Queued the previous patches, many thanks for importing things!","author":"pulkit","id":"115312","dateCreated":"1578933475","dateModified":"1578933475"},{"type":"inline","comment":"+1, I'm not sure what the use case for this would be in core.","replyTo":"111444","isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/c_api.rs","diffId":"18545","author":"durin42","id":"111896","dateCreated":"1576086289","dateModified":"1576086289"},{"type":"inline","comment":"My bad, it looks like you took care of it in a future patch.","replyTo":"111445","isNewFile":"1","line":"226","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111457","dateCreated":"1575896534","dateModified":"1575896534"},{"type":"inline","comment":"`pest` is really cool.","replyTo":null,"isNewFile":"1","line":"63","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/spec.pest","diffId":"18545","author":"Alphare","id":"111449","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"Is this hack still needed as of `1.34.2`?","replyTo":null,"isNewFile":"1","line":"595","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111448","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"Our current strategy is to assume config files to be in local encoding, not UTF-8. This makes sense from Facebook's perspective, but now as an upstream solution (see previous work on `HgPath`).","replyTo":null,"isNewFile":"1","line":"413","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111447","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"+1","replyTo":"111406","isNewFile":"1","line":"262","lineLength":"1","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18535","author":"Alphare","id":"111446","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"This function looks very Facebook specific, I don't think we want to include it at all.","replyTo":null,"isNewFile":"1","line":"226","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111445","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"Do we need bindings to C ? I don't see what the use-case is at this stage of the Rust development.","replyTo":null,"isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/c_api.rs","diffId":"18545","author":"Alphare","id":"111444","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"update","diffId":"18545","author":"indygreg","id":"111411","dateCreated":"1575774205","dateModified":"1575774205"},{"type":"comment","comment":"Thank you for the feedback, @quark! You enlightened me to a few issues I missed during my very quick perusal.\n\nI agree that doing away with the auto-generated `parser.rs` feels like a better solution. I may revise this series yet again...","author":"indygreg","id":"111408","dateCreated":"1575760222","dateModified":"1575760222"},{"type":"inline","comment":"You might want to revert D13875655 for the directory include feature, which has some test changes.","replyTo":null,"isNewFile":"1","line":"72","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/config.rs","diffId":"18535","author":"quark","id":"111407","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"inline","comment":"You might want to respect `$PAGER`. We ignored it to reduce support burden for mis-configuration. ","replyTo":null,"isNewFile":"1","line":"262","lineLength":"1","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18535","author":"quark","id":"111406","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"inline","comment":"You might want to remove these lines.","replyTo":null,"isNewFile":"1","line":"141","lineLength":"3","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18535","author":"quark","id":"111405","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"inline","comment":"You might want to follow this and remove the generated code.","replyTo":null,"isNewFile":"1","line":"103","lineLength":"4","path":"rust\/hg-core\/src\/configparser\/generate_parser.py","diffId":"18535","author":"quark","id":"111404","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"update","diffId":"18535","author":"indygreg","id":"111333","dateCreated":"1575749870","dateModified":"1575749870"}],"dateCreated":"1575749870","dateModified":"1606394587","status":"Needs Revision"},{"id":"9283","callsign":"HG","title":"bundle: optional multithreaded compression, ATM zstd-only","author":"joerg.sonnenberger","summary":"Compression type can be a huge chunk of \"hg bundle\", especially when\nusing the higher compression levels. With level=22 and threads=7, the\nNetBSD test repository took 28:39 wall time and 157:47 user time.\nBefore, level=22 would take 129:20 wall time and 129:07 user time.","testPlan":"","lineCount":"41","dependsOn":[],"reviewers":[],"ccs":["indygreg","mercurial-patches"],"actions":[{"type":"comment","comment":"I was looking specifically at bzip2 for a bit. There are essentially two kinds of threaded compressors for it. pbzip2 is the more common and creates effectively multiple independent streams. That's not handled transparently by Python's bz2, so it would break all existing clients, making this a big no-go. Sourceforge has a more proper implementation for POSIX platforms (http:\/\/bzip2smp.sourceforge.net\/) which doesn't have that problem and it would be nice if someone re-implemented the idea for modern libbz2. It can be done cleaner too. While this doesn't allow multi-threaded decompression for multi-stream-aware clients, it does work with all bzip2 decoders. Sadly the way it is done can't be from Python without re-implementing a good chunk of bz2 as it hooks deeply into the implementation. So in short, it would be possible to provide it as C extension and possibly even vendored, but it is more work than I currently want to do. I haven't looked into the state of pigz.","author":"joerg.sonnenberger","id":"140818","dateCreated":"1605993884","dateModified":"1605993884"},{"type":"inline","comment":"I thought we don't support generic python-zstandard at this point anyway? That said, if a user has a zstd build without, it would result in an error when asking for non-default options, which sounds perfectly acceptable to me.","replyTo":"139730","isNewFile":"1","line":"689","lineLength":"0","path":"mercurial\/utils\/compression.py","diffId":"23435","author":"joerg.sonnenberger","id":"140401","dateCreated":"1605718223","dateModified":"1605718223"},{"type":"inline","comment":"Primarily because otherwise the code has to check a list before querying the config option to avoid warnings. In principle, there are concurrent implementations of both gzip and bzip2, just not available as nicely packaged library. Emulating the bzip2 behavior in a small work queue would actually be moderately easy, I think. But I'm not sure how much interest there is still in bzip2 compression.","replyTo":"139729","isNewFile":"1","line":"551","lineLength":"8","path":"mercurial\/configitems.py","diffId":"23435","author":"joerg.sonnenberger","id":"140400","dateCreated":"1605718223","dateModified":"1605718223"},{"type":"inline","comment":"Multithreaded compression is a compile-time feature. python-zstandard builds the zstd library with this feature enabled. But I'm unsure what downstream packagers who unbundle libzstd are doing. For all I know they have removed the feature.\n\nI'm fine with landing this and letting packagers who insist on making their lives difficult deal with it.","replyTo":null,"isNewFile":"1","line":"689","lineLength":"0","path":"mercurial\/utils\/compression.py","diffId":"23435","author":"indygreg","id":"139730","dateCreated":"1604982376","dateModified":"1604982376"},{"type":"inline","comment":"None of these support compression. So why define the config options and give false promises?","replyTo":null,"isNewFile":"1","line":"551","lineLength":"8","path":"mercurial\/configitems.py","diffId":"23435","author":"indygreg","id":"139729","dateCreated":"1604982376","dateModified":"1604982376"},{"type":"update","diffId":"23435","author":"joerg.sonnenberger","id":"139598","dateCreated":"1604864992","dateModified":"1604864992"}],"dateCreated":"1604864992","dateModified":"1605993884","status":"Needs Review"},{"id":"9061","callsign":null,"title":"test: add bookmark for 'log' in test-completion","author":"sebhtml","summary":"$ .\/run-tests.py\nrunning 931 tests using 4 parallel processes\n...\nFailed test-contrib-emacs.t: output changed\nFailed test-convert-mtn.t: output changed\nFailed test-https.t: output changed\n# Ran 875 tests, 56 skipped, 3 failed.","testPlan":"","lineCount":"2","dependsOn":["9060"],"reviewers":["pulkit","martinvonz"],"ccs":["martinvonz"],"actions":[{"type":"comment","comment":"D8973 was dropped, so this cannot be queued in its current form","author":"martinvonz","id":"139658","dateCreated":"1604944100","dateModified":"1604944100"},{"type":"reject","author":"martinvonz","id":"139656","dateCreated":"1604944100","dateModified":"1604944100"},{"type":"accept","author":"pulkit","id":"136177","dateCreated":"1600930851","dateModified":"1600930851"},{"type":"update","diffId":"22747","author":"sebhtml","id":"135808","dateCreated":"1600529736","dateModified":"1600529736"}],"dateCreated":"1600529736","dateModified":"1605230124","status":"Needs Revision"},{"id":"9060","callsign":null,"title":"test: test 'hg log' using a bookmark","author":"sebhtml","summary":"","testPlan":"","lineCount":"167","dependsOn":[],"reviewers":["pulkit","martinvonz"],"ccs":["martinvonz"],"actions":[{"type":"comment","comment":"D8973 was dropped, so this cannot be queued in its current form","author":"martinvonz","id":"139652","dateCreated":"1604944085","dateModified":"1604944085"},{"type":"reject","author":"martinvonz","id":"139650","dateCreated":"1604944085","dateModified":"1604944085"},{"type":"accept","author":"pulkit","id":"136175","dateCreated":"1600930814","dateModified":"1600930814"},{"type":"comment","comment":"I also ran all the tests.\n\n# Ran 875 tests, 56 skipped, 4 failed.\n\n**Failed test-completion.t: output changed**\n\n```\n\n-  log: follow, follow-first, date, copies, keyword, rev, line-range, removed, only-merges, user, only-branch, branch, prune, patch, git, limit, no-merges, stat, graph, style, template, include, exclude\n+  log: follow, follow-first, date, copies, keyword, rev, line-range, removed, only-merges, user, only-branch, branch, bookmark, prune, patch, git, limit, no-merges, stat, graph, style, template, include, exclude\n\n```\n\nI will fix this.\n\n\n**Failed test-contrib-emacs.t: output changed**\n\n\n```\n-     passed  1\/1  hg-test-mode--compilation-mode-support\n+     passed  1\/1  hg-test-mode--compilation-mode-support (0.035108 sec)\n   \n-  Ran 1 tests, 1 results as expected (*) (glob)\n+  Ran 1 tests, 1 results as expected, 0 unexpected (2020-09-19 13:52:31+0000, 0.035428 sec)\n   \n```\n\nThe difference is the added elapsed time. It's unrelated to what I changed.\n\n**Failed test-convert-mtn.t: output changed**\n\n\n```\n+  mtn: warning: ssh_agent: failed to connect to agent: $ENOENT$\n\n```\n\nUnrelated.\n\n\n**Failed test-https.t: output changed**\n\n\n\n```\n   $ P=\"$CERTSDIR\" hg --config hostsecurity.ciphers=invalid -R copy-pull id https:\/\/localhost:$HGPORT\/\n-  abort: could not set ciphers: No cipher can be selected.\n-  (change cipher string (invalid) in config)\n-  [255]\n+  5fed3813f7f5\n```\n\nUnrelated too.","author":"sebhtml","id":"135806","dateCreated":"1600524516","dateModified":"1600524516"},{"type":"comment","comment":"It seems to work as expected:\n\n\n```\n$ .\/run-tests.py test-log-bookmark.t\nrunning 1 tests using 1 parallel processes \n.\n# Ran 1 tests, 0 skipped, 0 failed.\n\n```","author":"sebhtml","id":"135805","dateCreated":"1600521628","dateModified":"1600521628"},{"type":"update","diffId":"22746","author":"sebhtml","id":"135798","dateCreated":"1600521434","dateModified":"1600521434"}],"dateCreated":"1600521434","dateModified":"1605230124","status":"Needs Revision"},{"id":"6987","callsign":"HG","title":"debugstrip: add debugstrip to core","author":"navaneeth.suresh","summary":"Until now, `strip` was bootstrapped as an extension. This patch adds\n`debugstrip` on core. For the users who are still used to `strip`\nextension, we will preserve that name.","testPlan":"","lineCount":"362","dependsOn":[],"reviewers":["durin42","baymax"],"ccs":["pulkit","marmoute","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117501","dateCreated":"1579887099","dateModified":"1579887099"},{"type":"reject","author":"baymax","id":"117500","dateCreated":"1579887099","dateModified":"1579887099"},{"type":"update","diffId":"17120","author":"navaneeth.suresh","id":"103852","dateCreated":"1570917594","dateModified":"1570917594"},{"type":"inline","comment":"the documentation should be left as it is.","replyTo":null,"isNewFile":"1","line":"3","lineLength":"0","path":"hgext\/strip.py","diffId":"16914","author":"pulkit","id":"103145","dateCreated":"1570629357","dateModified":"1570629357"},{"type":"inline","comment":"What is going on here? IT seems like the same code with a different formatting.","replyTo":null,"isNewFile":"1","line":"24","lineLength":"10","path":"hgext\/strip.py","diffId":"16914","author":"marmoute","id":"102942","dateCreated":"1570496789","dateModified":"1570496789"},{"type":"inline","comment":"Why do we need that much code to remain into `hgext\/strip.py`. What I would expect to see is a very small file that only register debugstrip as `strip`.","replyTo":null,"isNewFile":"1","line":"1","lineLength":"46","path":"hgext\/strip.py","diffId":"16914","author":"marmoute","id":"102941","dateCreated":"1570496789","dateModified":"1570496789"},{"type":"comment","comment":"@durin42 Done,","author":"navaneeth.suresh","id":"102681","dateCreated":"1570384371","dateModified":"1570384371"},{"type":"update","diffId":"16914","author":"navaneeth.suresh","id":"102677","dateCreated":"1570384085","dateModified":"1570384085"},{"type":"inline","comment":"One or two is fine, you can leave the majority on the legacy extension flavor. We want some using each so we don't have to add a new test to test one of them.","replyTo":"102399","isNewFile":"1","line":"5646","lineLength":"0","path":"mercurial\/commands.py","diffId":"16856","author":"durin42","id":"102414","dateCreated":"1570309334","dateModified":"1570309334"},{"type":"inline","comment":"i see. do i need to replace `strip` by `debugstrip` on every occurrence in tests? otherwise, i would have to revert the changes in the tests and keep the extension as it is.","replyTo":"102397","isNewFile":"1","line":"5646","lineLength":"0","path":"mercurial\/commands.py","diffId":"16856","author":"navaneeth.suresh","id":"102399","dateCreated":"1570306240","dateModified":"1570306240"},{"type":"inline","comment":"debugstrip please (and put it in debugcommands)\n\nand Gregory points out we need a strip extension that preserves the old `strip` name for users that are used to that","replyTo":null,"isNewFile":"1","line":"5646","lineLength":"0","path":"mercurial\/commands.py","diffId":"16856","author":"durin42","id":"102397","dateCreated":"1570305353","dateModified":"1570305353"},{"type":"reject","author":"durin42","id":"102396","dateCreated":"1570305353","dateModified":"1570305353"},{"type":"update","diffId":"16856","author":"navaneeth.suresh","id":"102389","dateCreated":"1570304463","dateModified":"1570304463"}],"dateCreated":"1570304463","dateModified":"1604880960","status":"Needs Revision"},{"id":"7631","callsign":"HG","title":"absorb: allowing committed changes to be absorbed into their ancestors","author":"rdamazio","summary":"Like before, absorb continues to not touch the working directory, so any\nworking directory changes are preserved, even if the working directory parent\nchanges underneath (for instance, because the current revision was replaced\nwhen changes were absorbed into it).\n\nThis can also be combined with --interactive to absorb just part of a\ncommit into its parents.\n\nThis initial implementation has the shortcoming that it does not do anything\nwith the absorbed commit:\n- With obsmarkers, this means the user still needs to evolve, rebase or prune\n  manually\n- Without obsmarkers, the old commits would not be stripped at all because\n  their child was not replaced","testPlan":"","lineCount":"684","dependsOn":[],"reviewers":["martinvonz","marmoute"],"ccs":["mjacob","marmoute","mharbison72","martinvonz","pulkit","quark","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7631#123321, @mharbison72 wrote:\n>>>! In D7631#123318, @mjacob wrote:\n>> I like the name `--from` for the option. It would also make sense in combination with a possible future `--into` option.\n> \n> The unfortunate thing about `--from` is that it implies a range in `hg fold`, whereas here it seems to be a single(?) commit.  It does make a lot of sense within the context of this command though (i.e. taking stuff \/\/from\/\/ this commit).  And it took me awhile to get comfortable with the meaning in `hg fold`, so maybe it can be changed to something else there?  In any event, I don't want to hold this up over an experimental name, just thinking out loud.\n\nThe `--from` in `hg fold` does not only have a different meaning, it\u2019s also a flag that does not take an argument. The `hg fold` command itself takes revisions as arguments, so people might think they pass a revision to `--from` while they actually pass a revision to `hg fold` (having the same meaning as if it is passed to `-r`). Coincidentally, I was asked for help today from someone misusing the command that way. The `hg rewind` command also takes a `--from` option, this time with an argument. I expect that at least one of it might get changed eventually and I think we should not block this patch on that discussion.\n\nOf course, if someone comes up with a name that doesn\u2019t have these problems and is intuitive, we should use that name.\n\n> I tend to agree with @martinvonz that setting the successor back to the commit it was absorbed into would be confusing, and seems like a way to split the stack into two stacks on that destination, with the corresponding merge conflicts.  (Would the new \"`hg evolve` => stabilize all descendants functionality\" even stop at the break?  I don't think it would.)  I get what you're going for though if you want to track content.  But it seems like it would cause non power users a lot of confusion.\n\nI prepared a patch that helps to prevent that the stack gets split: https:\/\/foss.heptapod.net\/mercurial\/evolve\/merge_requests\/126\n\nAs an example:\n\n```\necho a > a; hg add a; hg ci -m a\necho b > b; hg add b; hg ci -m b\necho c > c; hg add c; hg ci -m c\necho a1 > a; echo b1 > b; hg ci -m 'change a and b'\necho d > d; hg add d; hg ci -m d\n```\n\nGraph:\n```\n@  (4) d\n|\no  (3) change a and b\n|\no  (2) c\n|\no  (1) b\n|\no  (0) a\n```\n\nFirst, let\u2019s emulate a run of `hg absorb --from 3` that adds markers.\n```\nhg up 3\nhg uncommit --all\nhg up 2 --merge\nhg absorb --apply-changes\nhg prune -r 5 -s '6 + 7' --split\n```\n\nGraph:\n```\n@  (8) c\n|\no  (7) b\n|\no  (6) a\n\n*  (4) d\n|\nx  (3) change a and b \u2014 split using prune, uncommit as 6, 7\n|\nx  (2) c \u2014 rebased using absorb as 8\n|\nx  (1) b \u2014 rewritten using absorb as 7\n|\nx  (0) a \u2014 amended using absorb as 6\n```\n\nNow, `hg evolve -r 4` would have the following result without the above patch:\n```\no  (9) d\n|\n| @  (8) c\n|\/\no  (7) b\n|\no  (6) a\n\n```\n\nand with the above patch:\n```\no  (9) d\n|\n@  (8) c\n|\no  (7) b\n|\no  (6) a\n```","author":"mjacob","id":"123546","dateCreated":"1583965232","dateModified":"1583965232"},{"type":"comment","comment":">>! In D7631#123318, @mjacob wrote:\n> I like the name `--from` for the option. It would also make sense in combination with a possible future `--into` option.\n\nThe unfortunate thing about `--from` is that it implies a range in `hg fold`, whereas here it seems to be a single(?) commit.  It does make a lot of sense within the context of this command though (i.e. taking stuff \/\/from\/\/ this commit).  And it took me awhile to get comfortable with the meaning in `hg fold`, so maybe it can be changed to something else there?  In any event, I don't want to hold this up over an experimental name, just thinking out loud.\n\nI tend to agree with @martinvonz that setting the successor back to the commit it was absorbed into would be confusing, and seems like a way to split the stack into two stacks on that destination, with the corresponding merge conflicts.  (Would the new \"`hg evolve` => stabilize all descendants functionality\" even stop at the break?  I don't think it would.)  I get what you're going for though if you want to track content.  But it seems like it would cause non power users a lot of confusion.","author":"mharbison72","id":"123321","dateCreated":"1583899488","dateModified":"1583899488"},{"type":"inline","comment":"My preferred option would be to add obsmarkers from the absorbed changeset to the changed changesets. This is what I would usually do if I do a poor man\u2019s version of this functionality: I uncommit the \"source\" changeset, absorb, and prune the \"source\" changeset with the changed changesets as the successor.\n\nIt is true that `hg evolve` is likely to not behave in a useful manner in this case. But as someone who almost always specifies a successor when pruning, I already run into these problems regularly. Fixing that is probably out of scope for this discussion.\n\nI tend to say that adding obsmarkers should be part of this patch, but I\u2019m not very familiar with Mercurial\u2019s preferred workflow for things like this.","replyTo":"120507","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"mjacob","id":"123320","dateCreated":"1583896507","dateModified":"1583896507"},{"type":"inline","comment":"I know that it was named like this before, but the name `targetctx` is quite confusing here, especially considering that the user-facing option will be something like `--from` or `--source`.\n\nCan it be changed, in a separate patch, after there is consensus about how the option should be called?","replyTo":null,"isNewFile":"1","line":"983","lineLength":"0","path":"hgext\/absorb.py","diffId":"19981","author":"mjacob","id":"123319","dateCreated":"1583896507","dateModified":"1583896507"},{"type":"comment","comment":"I like the name `--from` for the option. It would also make sense in combination with a possible future `--into` option.","author":"mjacob","id":"123318","dateCreated":"1583896507","dateModified":"1583896507"},{"type":"comment","comment":">>! In D7631#120777, @marmoute wrote:\n> 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.\n> \n> See the linked comment for more details.\n> \n> (Sorry for the delay this will involves, I wish the idea had explicitly surfaced earlier).\n\nThe sprint is not happening and I don't think we should wait for the next sprint (fall?) to move forward with this. Here's a Plan Page I wrote down in response to @marmoute's request D8030: on https:\/\/www.mercurial-scm.org\/wiki\/RevisionAsWDirPlan. The decision we reached was to use the name `--at-rev` on that patch. However, and if I understood correctly, the general sentiment was not that all similar arguments (like the on in this patch) should use that but rather that we should pick a name that sounded for each command. So in the case of this patch, I suppose `--from` is fine? We should mark it EXPERIMENTAL, though.\n","author":"martinvonz","id":"123178","dateCreated":"1583818890","dateModified":"1583818890"},{"type":"comment","comment":"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.\n\nSee the linked comment for more details.\n\n(Sorry for the delay this will involves, I wish the idea had explicitly surfaced earlier).","author":"marmoute","id":"120777","dateCreated":"1581636662","dateModified":"1581636662"},{"type":"reject","author":"marmoute","id":"120775","dateCreated":"1581636662","dateModified":"1581636662"},{"type":"inline","comment":"please revert (sorry about this annoying effect of copy detection)","replyTo":null,"isNewFile":"1","line":"4","lineLength":"3","path":"relnotes\/5.3","diffId":"19981","author":"martinvonz","id":"120508","dateCreated":"1581445540","dateModified":"1581445540"},{"type":"inline","comment":"I think we should at least have a TODO about adding them.\n\nBy the way, without the next patch's auto-evolve feature, I'm not sure we should add such markers. I think they would trick `hg evolve` into moving any descendant commits onto the topmost commit that was absorbed into, but that's probably not what the user wants (they probably want child commits to be moved onto the absorbed commit's parent).","replyTo":"118995","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"martinvonz","id":"120507","dateCreated":"1581445540","dateModified":"1581445540"},{"type":"comment","comment":"Sorry about the delay in responding. Please remember to rebase the series to the latest @ on hg-committed (the release notes are otherwise likely to conflict).","author":"martinvonz","id":"120506","dateCreated":"1581445540","dateModified":"1581445540"},{"type":"reject","author":"martinvonz","id":"120505","dateCreated":"1581445540","dateModified":"1581445540"},{"type":"update","diffId":"19981","author":"rdamazio","id":"119744","dateCreated":"1581045061","dateModified":"1581045061"},{"type":"update","diffId":"19979","author":"rdamazio","id":"119740","dateCreated":"1581044150","dateModified":"1581044150"},{"type":"inline","comment":"See the child commit (D7630), which adds the \"evolve\" operation.\n\nBecause of the invariant about parent phases, checking that the revision being absorbed is not public also ensures that everything it's absorbing into is not public. Is that what you were looking for? If the commit A being absorbed is a draft and its parent is public, then absorb just won't find anywhere to absorb the lines and will leave everything in A.\n\nAbout setting obsmarkers from the absorbed commit into the targets, while that's technically correct, I suspect it'll become a hard-to-navigate mess which adds very little. Do you want me to add that?","replyTo":"115317","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"rdamazio","id":"118995","dateCreated":"1580541031","dateModified":"1580541031"},{"type":"comment","comment":"Sorry for the delay in replying here.","author":"rdamazio","id":"118994","dateCreated":"1580541031","dateModified":"1580541031"},{"type":"update","diffId":"19811","author":"rdamazio","id":"118989","dateCreated":"1580541025","dateModified":"1580541025"},{"type":"inline","comment":"That's true in cmd.exe, but msys doesn't seem to care.  (That said, I thought check-code enforced quoting around `^`.)","replyTo":"115318","isNewFile":"1","line":"63","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"19048","author":"mharbison72","id":"116260","dateCreated":"1579193370","dateModified":"1579193370"},{"type":"inline","comment":"nit: I think I've heard that `^` needs to be quoted on Windows, so maybe `-s '.^+.'`","replyTo":null,"isNewFile":"1","line":"63","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"19048","author":"martinvonz","id":"115318","dateCreated":"1578936681","dateModified":"1578936681"},{"type":"inline","comment":"Maybe I'm also misunderstanding what this patch does in that case. `hg absorb -r A` will not obsolete A? I would think it definitely should do that. Perhaps the successors or the absorbed commit should be all the nodes absorbed into as well as any potential leftovers (which were not absorbed).","replyTo":"115301","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"martinvonz","id":"115317","dateCreated":"1578936681","dateModified":"1578936681"},{"type":"comment","comment":">>! In D7631#112604, @rdamazio wrote:\n>>>! In D7631#112414, @quark wrote:\n>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n> \n> Done. Used `--source` to match `rebase`.\n\nSorry I didn't notice until now, but `--source` makes me think it will behave like `hg rebase --source` and absorb from the given commit and all its descendants. I would have preferred `--from` (and maybe a `--into` for choosing which commits to absorb into in the future).","author":"martinvonz","id":"115316","dateCreated":"1578936681","dateModified":"1578936681"},{"type":"inline","comment":"I locally added some `hg log --graph` calls before and after absorb call to understand what happens. It will be nice to add them as it will make things easier for others to understand.","replyTo":null,"isNewFile":"1","line":"72","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"19048","author":"pulkit","id":"115302","dateCreated":"1578931522","dateModified":"1578931522"},{"type":"inline","comment":"Sorry, I misunderstood the patch earlier. `rewriteutil.precheck` on target rev is not very helpful as we are not obsolete-ing that in this rev, but we are re-writing it's ancestors. So, if target-rev is a head, and `evolution.alloworphans=False` is set, it will still create orphans.\n\nNot sure what's the best way forward, maybe we should do `rewriteutil.precheck` for the parent instead until we start obsoleting this rev.","replyTo":"113171","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"pulkit","id":"115301","dateCreated":"1578931522","dateModified":"1578931522"},{"type":"inline","comment":"I suspect other places may want something similar (e.g. it'd make sense in `rebase --dest`, so I changed revsingle to add the behavior.","replyTo":"114395","isNewFile":"1","line":"1141","lineLength":"0","path":"hgext\/absorb.py","diffId":"18873","author":"rdamazio","id":"114545","dateCreated":"1578358005","dateModified":"1578358005"},{"type":"comment","comment":">>! In D7631#114393, @mharbison72 wrote:\n>>>! In D7631#112604, @rdamazio wrote:\n>>>>! In D7631#112414, @quark wrote:\n>>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n>> \n>> Done. Used `--source` to match `rebase`.\n> \n> Is `--exact` from `hg fold` a better model?  I don't feel strongly; I only mention it because `hg rebase -s` will take that revision and its descendants, so it's more like \"stack\" in my mind.  I'm not sure how many other commands have `-s` off the top of my head, but @martinvonz \n> mentioned adding that to `hg fix` (probably in IRC), and I think mentioned the word \"stack\" in that context.  So I might not be the only one to get slightly tripped up by that.\n\nIMHO no, needing `--exact` is actually confusing to almost every user we've talked to, and they'd instead expect that to be the default behavior, with \"fold up to this commit\" being the one that needs a specific flag.\n\n>> I'm assuming no fundamental objections then? Removing the \"RFC\" part so it gets a proper review then.\n> \n> I like it.\n\nThanks","author":"rdamazio","id":"114544","dateCreated":"1578358005","dateModified":"1578358005"},{"type":"update","diffId":"19048","author":"rdamazio","id":"114541","dateCreated":"1578357966","dateModified":"1578357966"},{"type":"inline","comment":"Should it abort if multiple revisions are given, instead of picking the latest?","replyTo":null,"isNewFile":"1","line":"1141","lineLength":"0","path":"hgext\/absorb.py","diffId":"18873","author":"mharbison72","id":"114395","dateCreated":"1577996461","dateModified":"1577996461"},{"type":"comment","comment":">>! In D7631#112604, @rdamazio wrote:\n>>>! In D7631#112414, @quark wrote:\n>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n> \n> Done. Used `--source` to match `rebase`.\n\nIs `--exact` from `hg fold` a better model?  I don't feel strongly; I only mention it because `hg rebase -s` will take that revision and its descendants, so it's more like \"stack\" in my mind.  I'm not sure how many other commands have `-s` off the top of my head, but @martinvonz \nmentioned adding that to `hg fix` (probably in IRC), and I think mentioned the word \"stack\" in that context.  So I might not be the only one to get slightly tripped up by that.\n\n> I'm assuming no fundamental objections then? Removing the \"RFC\" part so it gets a proper review then.\n\nI like it.\n","author":"mharbison72","id":"114394","dateCreated":"1577996461","dateModified":"1577996461"},{"type":"update","diffId":"18873","author":"rdamazio","id":"113351","dateCreated":"1576740998","dateModified":"1576740998"},{"type":"inline","comment":"s\/--rev\/--source","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"relnotes\/next","diffId":"18843","author":"pulkit","id":"113262","dateCreated":"1576655750","dateModified":"1576655750"},{"type":"inline","comment":"s\/--rev\/--source","replyTo":null,"isNewFile":"1","line":"1113","lineLength":"0","path":"hgext\/absorb.py","diffId":"18843","author":"pulkit","id":"113261","dateCreated":"1576655750","dateModified":"1576655750"},{"type":"update","diffId":"18843","author":"rdamazio","id":"113172","dateCreated":"1576644411","dateModified":"1576644411"},{"type":"inline","comment":"Done. Notice that *technically* the user could do such an absorb while in the middle of a merge, but it sounds like a bad idea and inviting troubles, so I'm letting it also disallow that case. I'll be surprised if anyone even notices.","replyTo":"112977","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"rdamazio","id":"113171","dateCreated":"1576644173","dateModified":"1576644173"},{"type":"comment","comment":"> Can you describe the feature a bit in the commit message. Specific things which I feel are missing:\n\nDone\n\n> Also, it will be nice if you add an entry in releasenotes.\n\nDone\n","author":"rdamazio","id":"113170","dateCreated":"1576644173","dateModified":"1576644173"},{"type":"update","diffId":"18841","author":"rdamazio","id":"113166","dateCreated":"1576644148","dateModified":"1576644148"},{"type":"inline","comment":"need to do more checks here about being public commit etc. `rewriteutil.precheck` should help.","replyTo":null,"isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"pulkit","id":"112977","dateCreated":"1576585756","dateModified":"1576585756"},{"type":"inline","comment":"`hg status|diff` should be a better command here.","replyTo":null,"isNewFile":"1","line":"73","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"18728","author":"pulkit","id":"112976","dateCreated":"1576585756","dateModified":"1576585756"},{"type":"comment","comment":"Can you describe the feature a bit in the commit message. Specific things which I feel are missing:\n\n* what happens to wdir changes\n* what happens if source is a commit is not a head\n\nI understand them but after reading the tests, so might be worth to add them to description.\n\nAlso, it will be nice if you add an entry in releasenotes.","author":"pulkit","id":"112975","dateCreated":"1576585756","dateModified":"1576585756"},{"type":"update","diffId":"18728","author":"rdamazio","id":"112605","dateCreated":"1576304726","dateModified":"1576304726"},{"type":"comment","comment":">>! In D7631#112414, @quark wrote:\n> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n\nDone. Used `--source` to match `rebase`.\n\nI'm assuming no fundamental objections then? Removing the \"RFC\" part so it gets a proper review then.\n\n","author":"rdamazio","id":"112604","dateCreated":"1576303338","dateModified":"1576303338"},{"type":"update","diffId":"18726","author":"rdamazio","id":"112598","dateCreated":"1576303328","dateModified":"1576303328"},{"type":"comment","comment":"`--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?","author":"quark","id":"112414","dateCreated":"1576261313","dateModified":"1576261313"},{"type":"update","diffId":"18666","author":"rdamazio","id":"112231","dateCreated":"1576216539","dateModified":"1576216539"}],"dateCreated":"1576216539","dateModified":"1601479022","status":"Needs Revision"},{"id":"8982","callsign":"HG","title":"merge: disable `m2-vs-ma` diff optimization in case of flat manifests","author":"pulkit","summary":"4d504e541d3d1a139f8ebbf8c405291140fd1853 introduced an optimization where in\nsome cases we first diff ancestor and second parent, get the list of files\nchanged between them and then only diff for these files between first parent and\nsecond parent.\n\nHowever as the commit message mentions, this optimization is only helpful when\nrebasing very old commits and using treemanifest. On flat manifests, this\noptimization rather adds a bit of overhead.\n\nThis makes optimization not much useful on flat manifests and can be disabled.\n\nNow, while working on solving criss-cross merge issues where we want to create\nnew filenode for some files in initial merges, this optimization was causing\nissues. Since it's filters file for which diff needs to be performed, the files\nwe are concerned with gets filters out and we don't get to store anything\nrelated to those files.\n\nHence, want to disabling the optimization for flat manifests.\n\nThe tests changes are result of fact that we diff more files now in m1-vs-m2\ncomparison.\n\nSmall note: all these criss cross and new filenode thing I am talking about will\nbe behind a config flag. So nothing invasive yet :)","testPlan":"","lineCount":"47","dependsOn":[],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"I will get back to this later. This is no longer needed for the merge work I am doing.","author":"pulkit","id":"136897","dateCreated":"1601470365","dateModified":"1601470365"},{"type":"plan-changes","author":"pulkit","id":"136896","dateCreated":"1601470365","dateModified":"1601470365"},{"type":"update","diffId":"22668","author":"pulkit","id":"135301","dateCreated":"1600336153","dateModified":"1600336153"},{"type":"comment","comment":"Looks good. Out of curiosity, did you do any performance measurement of this?","author":"marmoute","id":"134987","dateCreated":"1599815158","dateModified":"1599815158"},{"type":"accept","author":"marmoute","id":"134986","dateCreated":"1599815158","dateModified":"1599815158"},{"type":"update","diffId":"22585","author":"pulkit","id":"134792","dateCreated":"1599659068","dateModified":"1599659068"},{"type":"update","diffId":"22546","author":"pulkit","id":"134535","dateCreated":"1599289699","dateModified":"1599289699"}],"dateCreated":"1599289699","dateModified":"1601470365","status":"Changes Planned"},{"id":"8977","callsign":"HG","title":"merge: check for dir rename dest before adding ACTION_KEEP","author":"pulkit","summary":"A previous patch in the series blindly uses `ACTION_KEEP` if the file is not\npresent on both remote and ancestor. This was wrong.\n\nWe tries to detect directory renames and in some graft cases, it can be possible\nthat file is not present on both sides but is created in rename destination of\nother directory which exists on remote. In such cases, we need to merge the\nrename source from remote with rename dest from local.\n\nThis patch makes sure we checks for such rename cases before falling back to\n`ACTION_KEEP`.\n\nAction for rename destination can be added while processing rename destination\nor processing rename source. In some cases, when an optimization only diffing\nfiles changes between m2-vs-ma are in play, either of rename dest or rename\nsource might not be processed.\nHence we need to be extra sure about adding action related to rename\ndestination.\n\nThis issue of missing to check dir rename dest was spotted by a future change\nwhere some tests were failing.","testPlan":"","lineCount":"67","dependsOn":[],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"I have some changes which need to be made to this patch according to Yuya's review on mailing list.","author":"pulkit","id":"135636","dateCreated":"1600434255","dateModified":"1600434255"},{"type":"plan-changes","author":"pulkit","id":"135635","dateCreated":"1600434255","dateModified":"1600434255"},{"type":"update","diffId":"22663","author":"pulkit","id":"135272","dateCreated":"1600336088","dateModified":"1600336088"},{"type":"comment","comment":">>! In D8977#135146, @pulkit wrote:\n>>>! In D8977#135054, @marmoute wrote:\n>> Why don't we get a test change with this ?\n> \n> The test changes are visible after disabling the m2-vs-ma optimization. I just plugged it before to minimize the test changes in that patch which disables the optimization.\n\nCan you mention it in the changeset description ?","author":"marmoute","id":"135147","dateCreated":"1600073677","dateModified":"1600073677"},{"type":"comment","comment":">>! In D8977#135054, @marmoute wrote:\n> Why don't we get a test change with this ?\n\nThe test changes are visible after disabling the m2-vs-ma optimization. I just plugged it before to minimize the test changes in that patch which disables the optimization.","author":"pulkit","id":"135146","dateCreated":"1600072367","dateModified":"1600072367"},{"type":"comment","comment":"Why don't we get a test change with this ?","author":"marmoute","id":"135054","dateCreated":"1599828886","dateModified":"1599828886"},{"type":"reject","author":"marmoute","id":"135053","dateCreated":"1599828886","dateModified":"1599828886"},{"type":"update","diffId":"22514","author":"pulkit","id":"134408","dateCreated":"1599047687","dateModified":"1599047687"}],"dateCreated":"1599047687","dateModified":"1600434255","status":"Changes Planned"},{"id":"8968","callsign":"HG","title":"phabricator: Pass through diffoptions","author":"sfink","summary":"","testPlan":"","lineCount":"24","dependsOn":["8524"],"reviewers":["Alphare","indygreg"],"ccs":["indygreg","Alphare","Kwan","mercurial-patches"],"actions":[{"type":"inline","comment":"Mutable default argument.","replyTo":null,"isNewFile":"1","line":"1082","lineLength":"0","path":"hgext\/phabricator.py","diffId":"22486","author":"indygreg","id":"135499","dateCreated":"1600394981","dateModified":"1600394981"},{"type":"inline","comment":"It's weird to pass an `options` dict\/argument only to use a single key.\n\nPerhaps we should do something like this instead:\n\n```\noptions = dict(options or {})\noptions['git'] = True\n\ndiffopts = mdiff.diffopts(**options)\n```","replyTo":null,"isNewFile":"1","line":"726","lineLength":"0","path":"hgext\/phabricator.py","diffId":"22486","author":"indygreg","id":"135498","dateCreated":"1600394981","dateModified":"1600394981"},{"type":"inline","comment":"`[]` and `{}` or any dynamic value should not be used as an argument default because the initially passed value will be used on subsequent invocations if it isn't passed. See https:\/\/docs.python-guide.org\/writing\/gotchas\/#mutable-default-arguments.\n\nFor this pattern, do something like:\n\n```\ndef func(optional=None):\n    optional = optional or {}\n```\n\nor\n\n```\ndef func(optional=None):\n    if optional is None:\n        optional = {}\n```","replyTo":null,"isNewFile":"1","line":"721","lineLength":"0","path":"hgext\/phabricator.py","diffId":"22486","author":"indygreg","id":"135497","dateCreated":"1600394981","dateModified":"1600394981"},{"type":"reject","author":"indygreg","id":"135496","dateCreated":"1600394981","dateModified":"1600394981"},{"type":"inline","comment":"I know it's not technically part of this change, but making `32767` a \"constant\" with an explanation or at least a good name would be nice.","replyTo":null,"isNewFile":"1","line":"725","lineLength":"0","path":"hgext\/phabricator.py","diffId":"22486","author":"Alphare","id":"134835","dateCreated":"1599725844","dateModified":"1599725844"},{"type":"accept","author":"Alphare","id":"134834","dateCreated":"1599725844","dateModified":"1599725844"},{"type":"comment","comment":"Nothing uses this directly, but it makes it much easier to another extension to call into this code and be able to request different diff options","author":"sfink","id":"134287","dateCreated":"1598648407","dateModified":"1598648407"},{"type":"update","diffId":"22486","author":"sfink","id":"134284","dateCreated":"1598648407","dateModified":"1598648407"}],"dateCreated":"1598648407","dateModified":"1600394981","status":"Needs Revision"},{"id":"7026","callsign":"HG","title":"treemanifest: move out of experimental","author":"pulkit","summary":"In recent sprint, we discussed that treemanifest should be moved out of\nexperimental. The feature has been used inside Google, Facebook in some forms\nand was used inside Yandex too for narrow clones.\n\nThere is an issue with diffing of large treemanifests and to fix that some\nPython code needs to be rewritted in C\/Rust. This I think is not a blocker for\ntaking treemanifest out of experimental.\n\nThis patch renames config `experimental.treemanifest` to `storage.treemanifest`.","testPlan":"","lineCount":"59","dependsOn":[],"reviewers":["durin42","baymax"],"ccs":["mercurial-patches","aayjaychan","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117498","dateCreated":"1579887097","dateModified":"1579887097"},{"type":"reject","author":"baymax","id":"117497","dateCreated":"1579887097","dateModified":"1579887097"},{"type":"comment","comment":"That sounds fine","author":"durin42","id":"104286","dateCreated":"1571179604","dateModified":"1571179604"},{"type":"comment","comment":"the storage session is more about small configuration of the storage \nsystem without impact on the repository. The `format` section is more \nappropriate for things that deeply impact the repository format.\n\nSo this should probably at least lives in the `format` as \n`format.use-tree-manifest`.\n\nHowever, this is also the first \"scheme\" change we get. repository using \ntree-manifest will never be able to push to a repository not using it. \nThat make `tree-manifest` different from anything that live in the \n`format` section right now.\n\nSo maybe: `format.manifest-scheme=tree-manifest` ?","author":"marmoute","id":"103128","dateCreated":"1570594672","dateModified":"1570594672"},{"type":"update","diffId":"16976","author":"pulkit","id":"103083","dateCreated":"1570568597","dateModified":"1570568597"}],"dateCreated":"1570568597","dateModified":"1599815758","status":"Needs Revision"},{"id":"8457","callsign":"HG","title":"[RFC] metadataonlyctx: demonstrate an error reusing manifest nodes","author":"mharbison72","summary":"Don't queue this, it's for demo purposes only.\n\nThe structure of the revisions being submitted here is admittedly insane, but I\nstumbled into this trying to test for another issue.  Since I don't see anything\nobviously wrong, I'm wondering if fix\/absorb\/etc would have similar issues here.\nI converted the RuntimeError to a message so that the operation completes and\ndoesn't rollback the transaction.","testPlan":"","lineCount":"842","dependsOn":[],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches","Kwan","mercurial-devel"],"actions":[{"type":"comment","comment":"Bug filed here: https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6305\n\nI wonder if D8989 has any effect on this.","author":"mharbison72","id":"134599","dateCreated":"1599327568","dateModified":"1599327568"},{"type":"comment","comment":"II recommend filling up a bug with a link to this Diff.","author":"marmoute","id":"126505","dateCreated":"1587589350","dateModified":"1587589350"},{"type":"comment","comment":">>! In D8457#126469, @marmoute wrote:\n> For demo purpose only \u2192 getting it out of review. Put it back in review if I am wrong.\n\nCorrect.  But I would like eyes on it because I have no clue what the problem is, and it might affect other extensions.","author":"mharbison72","id":"126502","dateCreated":"1587577837","dateModified":"1587577837"},{"type":"comment","comment":"For demo purpose only \u2192 getting it out of review. Put it back in review if I am wrong.","author":"marmoute","id":"126469","dateCreated":"1587572200","dateModified":"1587572200"},{"type":"reject","author":"marmoute","id":"126468","dateCreated":"1587572200","dateModified":"1587572200"},{"type":"update","diffId":"21153","author":"mharbison72","id":"126129","dateCreated":"1587136741","dateModified":"1587136741"}],"dateCreated":"1587136741","dateModified":"1599327568","status":"Needs Revision"},{"id":"8524","callsign":"HG","title":"phabricator: add .arcconfig to help messages and comments (issue6331)","author":"sfink","summary":"Wrapping localrepo's loadhgrc() was not working for me because it is too late to wrap loadhgrc when the extension is loaded.","testPlan":"","lineCount":"19","dependsOn":[],"reviewers":["mharbison72","marmoute"],"ccs":["pulkit","marmoute","Kwan","mercurial-patches"],"actions":[{"type":"comment","comment":">>! In D8524#134327, @mharbison72 wrote:\n>>>! In D8524#134326, @sfink wrote:\n>>>>! In D8524#134322, @mharbison72 wrote:\n>>> The documentation updates look good to me, but there are still some code changes that were probably not intentional, and the commit message probably needs an update.\n>> \n>> I updated the commit message to \"add .arcconfig to help messages and comments\", which seems accurate.\n> \n> I meant this, which is still in the summary section\n> \n>     Wrapping localrepo's loadhgrc() was not working for me because it is too late to wrap loadhgrc when the extension is loaded.\n\nI agree that this needs to be changed.\n\nRest looks good to me, will push once commit description is updated.\n> \n>> This is now the only code change (removing the explicit result variable and instead just using cfg to tell whether we updated any configuration.) This seems to better match the intent documented in mercurial\/localrepo.py:\n>>\n>>    Returns a bool indicating whether any additional configs were loaded.\n>>\n>> The only difference with the redundant result variable would be if you loaded in a .arcconfig that did not contain either of the two settings looked at here, and in that case it seems like it would be better to return False.\n>>\n>> What do you think?\n> \n> I understand now.  Yeah this code is better.  Usually we try to split unrelated documentation updates into a separate commit though, so can you `hg split` this (and get rid of the differential url in one of theme)?\n\n","author":"pulkit","id":"134457","dateCreated":"1599064670","dateModified":"1599064670"},{"type":"comment","comment":">>! In D8524#134326, @sfink wrote:\n>>>! In D8524#134322, @mharbison72 wrote:\n>> The documentation updates look good to me, but there are still some code changes that were probably not intentional, and the commit message probably needs an update.\n> \n> I updated the commit message to \"add .arcconfig to help messages and comments\", which seems accurate.\n\nI meant this, which is still in the summary section\n\n    Wrapping localrepo's loadhgrc() was not working for me because it is too late to wrap loadhgrc when the extension is loaded.\n\n> This is now the only code change (removing the explicit result variable and instead just using cfg to tell whether we updated any configuration.) This seems to better match the intent documented in mercurial\/localrepo.py:\n>\n>    Returns a bool indicating whether any additional configs were loaded.\n>\n> The only difference with the redundant result variable would be if you loaded in a .arcconfig that did not contain either of the two settings looked at here, and in that case it seems like it would be better to return False.\n>\n> What do you think?\n\nI understand now.  Yeah this code is better.  Usually we try to split unrelated documentation updates into a separate commit though, so can you `hg split` this (and get rid of the differential url in one of theme)?","author":"mharbison72","id":"134327","dateCreated":"1598737569","dateModified":"1598737569"},{"type":"comment","comment":">>! In D8524#134322, @mharbison72 wrote:\n> The documentation updates look good to me, but there are still some code changes that were probably not intentional, and the commit message probably needs an update.\n\nI updated the commit message to \"add .arcconfig to help messages and comments\", which seems accurate.\n\n>> It gets a little messy when uploading partial patches to code that I am patching\n> \n> Are you simply amending your local commit and reposting it with phabsend?  If not, I'm not sure what the state of it will be if someone imports it to land it.\n\nSorry, I said that wrong. Yes, I'm doing exactly what you're saying, it's just that the phabsend I'm using is coming from `mozphabricator.py` and I have a whole long stack of patches applied to it, and a corresponding stack of patches applied to `phabricator.py`, and I have to be sure to be in matching places in the stacks or things might get a little mangled (eg adding \"Bug None - Bug None - Bug None -\" to the beginning of the commit message).\n\n>>  Ok, the problem I was running into with the exthelper stuff is that it wasn't getting invoked, and it wasn't getting invoked because my extension did not set its uisetup at all. So the fix is very similar to the above: from hgext.phabricator import uisetup\n> \n> I've got a similar extension that wraps the command itself and changes all reviewers to blocking reviewers (so that the first accept doesn't drop it out of everybody else's queue).  I don't understand importing `hgext.phabricator.uisetup` though.  You should have this somewhere near the top of your extension like `phabricator.py` does\n> \n>     eh = exthelper.exthelper()\n>     ...\n>     uisetup = eh.finaluisetup\n> \n> The underlying machinery simply looks for attributes on the module like `uisetup()`, `reposetup()`, etc, and calls them if present.  And yeah, I get confused all the time about the differences between these hooks too.\n\nHm, you may be right. I hadn't needed `exthelper` for anything else in my wrapper yet, so I got rid of it entirely. (I was originally using it, but that meant when I did eg `commands = eh.commands` I wasn't \"inheriting\" the commands from `phabricator.py`. So I switched to `from hgext.phabricator import commands` and then modifying stuff as needed.)\n\nAnyway, whether I do `uisetup = eh.finaluisetup` or `from hgext.phabricator import uisetup` doesn't matter too much; it ends up having the same effect. Given that `phabricator.py` already has an `exthelper` object instantiated with configuration on it that I want to use, it seems a little odd to make another one in my module. Perhaps a midway point would be `from hgext.phabricator import eh` and then `commands = eh.commands` etc.\n","author":"sfink","id":"134326","dateCreated":"1598734153","dateModified":"1598734153"},{"type":"inline","comment":"This is now the only code change (removing the explicit `result` variable and instead just using `cfg` to tell whether we updated any configuration.) This seems to better match the intent documented in `mercurial\/localrepo.py`:\n```\n    Returns a bool indicating whether any additional configs were loaded.\n```\nThe only difference with the redundant `result` variable would be if you loaded in a `.arcconfig` that did not contain either of the two settings looked at here, and in that case it seems like it would be better to return `False`.\n\nWhat do you think?\n","replyTo":null,"isNewFile":"1","line":"203","lineLength":"0","path":"hgext\/phabricator.py","diffId":"22485","author":"sfink","id":"134325","dateCreated":"1598733384","dateModified":"1598733384"},{"type":"comment","comment":"The documentation updates look good to me, but there are still some code changes that were probably not intentional, and the commit message probably needs an update.\n\n> It gets a little messy when uploading partial patches to code that I am patching\n\nAre you simply amending your local commit and reposting it with phabsend?  If not, I'm not sure what the state of it will be if someone imports it to land it.\n\n>  Ok, the problem I was running into with the exthelper stuff is that it wasn't getting invoked, and it wasn't getting invoked because my extension did not set its uisetup at all. So the fix is very similar to the above: from hgext.phabricator import uisetup\n\nI've got a similar extension that wraps the command itself and changes all reviewers to blocking reviewers (so that the first accept doesn't drop it out of everybody else's queue).  I don't understand importing `hgext.phabricator.uisetup` though.  You should have this somewhere near the top of your extension like `phabricator.py` does\n\n    eh = exthelper.exthelper()\n    ...\n    uisetup = eh.finaluisetup\n\nThe underlying machinery simply looks for attributes on the module like `uisetup()`, `reposetup()`, etc, and calls them if present.  And yeah, I get confused all the time about the differences between these hooks too.\n","author":"mharbison72","id":"134322","dateCreated":"1598722113","dateModified":"1598722113"},{"type":"reject","author":"mharbison72","id":"134321","dateCreated":"1598722113","dateModified":"1598722113"},{"type":"comment","comment":"It gets a little messy when uploading partial patches to code that I am patching","author":"sfink","id":"134282","dateCreated":"1598645746","dateModified":"1598645746"},{"type":"update","diffId":"22485","author":"sfink","id":"134281","dateCreated":"1598645746","dateModified":"1598645746"},{"type":"comment","comment":"I thought I would at least keep the help message updates instead of scrapping the whole thing.","author":"sfink","id":"134279","dateCreated":"1598645388","dateModified":"1598645388"},{"type":"update","diffId":"22484","author":"sfink","id":"134276","dateCreated":"1598645388","dateModified":"1598645388"},{"type":"comment","comment":"I finally got around to looking at why I needed this. It turned out to be pretty complicated, and although this patch would work for me, I'm sure there are other ways to work around this so it may not make sense to land.\n\nAt first, I thought it was simple: the wrapped `loadhgrc` is defined in an extension, and knowing what extensions exist requires loading the `.hgrc` config file, so of course it can't possibly work and everybody who is using it successfully must be, uh, liars or something!\n\nBut it appears that this `loadhgrc` is only used for loading a repository's `.hg\/hgrc`, so the above logic is wrong.\n\nOk, here's where it gets weird. What I'm doing is making a \"wrapper\" extension `mozphabricator.py` that works by importing selected stuff from mercurial's in-tree `hgext\/phabricator.py`, and then overriding and monkeypatching what I want to change. The problem is that `phabricator.py` hooks into the repo-specific `.hgrc` loading via `@exthelper.exthelper().wrapfunction(localrepo, \"loadhgrc\")`. When I thought using `loadhgrc` was just completely wrong, the implementation was trivial: just do `from hgext.phabricator import reposetup` and it just works.\n\nAha! Ok, the problem I was running into with the `exthelper` stuff is that it wasn't getting invoked, and it wasn't getting invoked because my extension did not set its `uisetup` at all. So the fix is very similar to the above: `from hgext.phabricator import uisetup`.\n","author":"sfink","id":"134275","dateCreated":"1598638562","dateModified":"1598638562"},{"type":"comment","comment":"There seems to be extra explanation and style change required (as per @mharbisson72 comment).","author":"marmoute","id":"128599","dateCreated":"1591638000","dateModified":"1591638000"},{"type":"reject","author":"marmoute","id":"128598","dateCreated":"1591638000","dateModified":"1591638000"},{"type":"inline","comment":"`if not repo.local()` is the typical way to do this check.","replyTo":null,"isNewFile":"1","line":"175","lineLength":"0","path":"hgext\/phabricator.py","diffId":"21386","author":"mharbison72","id":"127507","dateCreated":"1589648649","dateModified":"1589648649"},{"type":"comment","comment":"I'll try to take a closer look at this some time this weekend.  In the meantime, can you explain more why it didn't work for you?  There are tests that cover this feature, so I'm wondering if some coverage is missing.\n\nI'm not sure if this is intentional, but it appears that it will unconditionally override even `.hg\/hgrc` configs if `.arcconfig` is present.  Before it would only override the global config, load `.arcconfig`, and then load `.hg\/hgrc`.  I guess it's only a small benefit that you could re-target the phab instance without dirtying the repo, so I'm not strongly against the change.\n\nOne of the lines looks like it might be long-ish, so you might want to run `.\/run-tests --local test-phabricator.t test-check-*` to make sure it's OK.","author":"mharbison72","id":"127506","dateCreated":"1589648649","dateModified":"1589648649"},{"type":"update","diffId":"21386","author":"sfink","id":"127460","dateCreated":"1589501713","dateModified":"1589501713"}],"dateCreated":"1589501713","dateModified":"1599064670","status":"Needs Revision"},{"id":"6776","callsign":null,"title":"bookmarks: validate changes on push (issue6193) (BC)","author":"idlsoft","summary":"The actual validation is in bundle2.handlebookmark.\nThe rest of the changes are there to pass the force parameter.\nI've also made force available to hooks. That way one can validate who can and cannot use --force on a shared repo.\n\nIn other words, in the case of:\n\n    o 2\n    |  o 1 @\n    o\/ 0\n\nwhen I last pulled, @ was on 0, and now I'm doing hg push -B @, but\nsince my last pull the server advanced @ to 2, meaning it's a\nnon-linear update of the bookmark. This used to be allowed, and is now\nprohibited without --force.\n\n.. bc::\n\n    `hg push --bookmark` and `hg push -B` no longer move a bookmark\n    during push if the new bookmark position isn't a descendant of the\n    current bookmark position.\n\n.. feature::\n\n    Hooks are now able to tell if --force was specified when a bookmark was pushed.","testPlan":"","lineCount":"203","dependsOn":[],"reviewers":["durin42","baymax"],"ccs":["mjacob","marmoute","pulkit","durin42","valentin.gatienbaron","mercurial-devel"],"actions":[{"type":"comment","comment":"I agree (with some previous answers) that adding more stuff to `--force` should be avoided.\n\nI planned to send a proposal (and patches) after the 5.5 release for adding more detailed options that can be used instead of `--force`. However, due to unexpected reasons, I don\u2019t know whether I\u2019ll have the time for doing that.","author":"mjacob","id":"133095","dateCreated":"1596747653","dateModified":"1596747653"},{"type":"comment","comment":"As I\n\n>>! In D6776#133068, @marmoute wrote:\n> As @valentin.gatienbaron pointed out, the now avoid adding more semantic to bare `--force` with an associated `--force-bookmark` especially because we want to be able to select the bookmarks that get force pushed here.\n\nI've expressed my concerns about that earlier, but ultimately it's a debate for core maintainers, we'll use whatever they decide.\nWithout a clear decision it didn't make much sense to modify the PR.\nI'm not sure if I'll have the bandwith to resume working on this, but glad to see it getting renewed attention.","author":"idlsoft","id":"133069","dateCreated":"1596736255","dateModified":"1596736255"},{"type":"comment","comment":"As @valentin.gatienbaron pointed out, the now avoid adding more semantic to bare `--force` with an associated `--force-bookmark` especially because we want to be able to select the bookmarks that get force pushed here.","author":"marmoute","id":"133068","dateCreated":"1596733563","dateModified":"1596733563"},{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117540","dateCreated":"1579887117","dateModified":"1579887117"},{"type":"reject","author":"baymax","id":"117539","dateCreated":"1579887117","dateModified":"1579887117"},{"type":"comment","comment":"> If you mean \"reject bad pushes as long as people don't push -f\", both versions implement this (the client-side check is not racy thanks to these check:bookmark bundle parts).\nThat was the idea. This implementation is a bit more flexible I think.\nSince it\u2019s server side, you don\u2019t have to upgrade your clients.\nIt\u2019s true old clients won\u2019t be able to use \u2014force, but new ones can.\nAnd you can add a trigger if you want to limit who can use \u2014force.\n\n","author":"idlsoft","id":"100533","dateCreated":"1568441725","dateModified":"1568441725"},{"type":"comment","comment":">>! In D6776#100506, @durin42 wrote:\n>>>! In D6776#100487, @valentin.gatienbaron wrote:\n>> I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.\n>> I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.\n> \n> Isn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)\n\nIf you mean \"reject bad pushes as long as people don't push -f\", both versions implement this (the client-side check is not racy thanks to these check:bookmark bundle parts).\nIf you mean \"reject bad pushes, push -f or not\", a server-side hook is necessary for that, and hook.pretxnclose-bookmark should be able to do the job without any server code change. Server code change can certainly simplify writing such checks, but passing the force parameter on the procol is not needed.","author":"valentin.gatienbaron","id":"100532","dateCreated":"1568440575","dateModified":"1568440575"},{"type":"update","diffId":"16534","author":"idlsoft","id":"100519","dateCreated":"1568436765","dateModified":"1568436765"},{"type":"update","diffId":"16533","author":"idlsoft","id":"100518","dateCreated":"1568428463","dateModified":"1568428463"},{"type":"update","diffId":"16531","author":"idlsoft","id":"100513","dateCreated":"1568420567","dateModified":"1568420567"},{"type":"comment","comment":"> Isn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)\n\nI updated the diff to propagate --force properly","author":"idlsoft","id":"100511","dateCreated":"1568410784","dateModified":"1568420628"},{"type":"comment","comment":">>! In D6776#100487, @valentin.gatienbaron wrote:\n> I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.\n> I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.\n\nIsn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)","author":"durin42","id":"100506","dateCreated":"1568382052","dateModified":"1568382052"},{"type":"comment","comment":"I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.\nI think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.\n","author":"valentin.gatienbaron","id":"100487","dateCreated":"1568349208","dateModified":"1568349208"},{"type":"update","diffId":"16524","author":"idlsoft","id":"100462","dateCreated":"1568310366","dateModified":"1568310366"},{"type":"inline","comment":"It will be nice to have documentation about what `force` does in the interface.","replyTo":null,"isNewFile":"1","line":"194","lineLength":"0","path":"mercurial\/interfaces\/repository.py","diffId":"16519","author":"pulkit","id":"100444","dateCreated":"1568268366","dateModified":"1568268366"},{"type":"inline","comment":"Hm, I think `conflicts` can be confusing but I don't have better suggestions here.","replyTo":null,"isNewFile":"1","line":"2149","lineLength":"0","path":"mercurial\/bundle2.py","diffId":"16519","author":"pulkit","id":"100443","dateCreated":"1568268366","dateModified":"1568268366"},{"type":"comment","comment":"I agree with @valentin.gatienbaron that `--force` is quite generic :(.  It may create new heads on the server even if I don't want to.","author":"pulkit","id":"100442","dateCreated":"1568268366","dateModified":"1568268366"},{"type":"comment","comment":"We're really close. I've uploaded my rebase of this to the latest dev hg (along with some minor test fixes). There's now only one failure:\n\n```--- \/Users\/augie\/Programming\/hg\/crew\/tests\/test-bookmarks-pushpull.t\n+++ \/Users\/augie\/Programming\/hg\/crew\/tests\/test-bookmarks-pushpull.t#b2-binary.err\n@@ -820,15 +820,17 @@\n   pushing to http:\/\/localhost:$HGPORT\/\n   searching for changes\n   no changes found\n-  updating bookmark Z\n-  [1]\n+  remote: push rejected: bookmark \"Z\" has changed\n+  remote: (run 'hg pull', resolve conflicts, and push again)\n+  abort: push failed on remote\n+  [255]\n   $ hg book -d Z\n   $ hg in -B http:\/\/localhost:$HGPORT\/\n   comparing with http:\/\/localhost:$HGPORT\/\n   searching for changed bookmarks\n      @                         9b140be10808\n      X                         9b140be10808\n-     Z                         0d2164f0ce0d\n+     Z                         9b140be10808\n      foo                       000000000000\n      foobar                    9b140be10808\n   $ hg pull -B Z http:\/\/localhost:$HGPORT\/\n@@ -853,7 +855,7 @@\n    * @                         1:9b140be10808\n      X                         1:9b140be10808\n      Y                         4:c922c0139ca0\n-     Z                         2:0d2164f0ce0d\n+     Z                         1:9b140be10808\n      foo                       -1:000000000000\n      foobar                    1:9b140be10808\n \n\nERROR: test-bookmarks-pushpull.t#b2-binary output changed\n```\n\nMy gut at this point is that we should:\n\n1) Document that legacy bookmark push behavior over pushkey is different\n2) Add a config to reject bookmark pushes over pushkey\n\nBut if there's a way to fix the pushkey behavior too, I'd be interested in that. I'm just not sure it's worth blocking on when that should only matter with very old servers. Obviously if others have stronger opinions they should speak up.","author":"durin42","id":"100418","dateCreated":"1568225245","dateModified":"1568225245"},{"type":"update","diffId":"16519","author":"durin42","id":"100417","dateCreated":"1568225133","dateModified":"1568225133"},{"type":"update","diffId":"16518","author":"idlsoft","id":"100413","dateCreated":"1568217168","dateModified":"1568217168"},{"type":"comment","comment":"I've uploaded my revised version (with the more complete commit message - no other changes) in case that helps.","author":"durin42","id":"100386","dateCreated":"1568212358","dateModified":"1568212358"},{"type":"reject","author":"durin42","id":"100385","dateCreated":"1568212358","dateModified":"1568212358"},{"type":"update","diffId":"16515","author":"durin42","id":"100382","dateCreated":"1568212309","dateModified":"1568212309"},{"type":"comment","comment":"I get a fair number of test failures with this, eg `test-bookmarks-corner-case.t`:\n\n```\n--- \/usr\/local\/google\/home\/augie\/hgtest\/tests\/test-bookmarks-corner-case.t\n+++ \/usr\/local\/google\/home\/augie\/hgtest\/tests\/test-bookmarks-corner-case.t.err\n@@ -178,11 +178,48 @@\n   $ hg push -R client-B -r book-B\n   pushing to ssh:\/\/user@dummy\/bookrace-server\n   searching for changes\n-  remote: adding changesets\n-  remote: adding manifests\n-  remote: adding file changes\n-  remote: added 1 changesets with 1 changes to 1 files\n-  updating bookmark book-B\n+  ** unknown exception encountered, please report by visiting\n+  ** https:\/\/mercurial-scm.org\/wiki\/BugTracker\n+  ** Python 2.7.16 (default, Apr  6 2019, 01:42:57) [GCC 7.3.0]\n+  ** Mercurial Distributed SCM (version 5.1.1+253-85a0f0de90e5)\n+  ** Extensions loaded:\n+  Traceback (most recent call last):\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/bin\/hg\", line 43, in <module>\n+      dispatch.run()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 99, in run\n+      status = dispatch(req)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 225, in dispatch\n+      ret = _runcatch(req) or 0\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 376, in _runcatch\n+      return _callcatch(ui, _runcatchfunc)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 384, in _callcatch\n+      return scmutil.callcatch(ui, func)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/scmutil.py\", line 167, in callcatch\n+      return func()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 367, in _runcatchfunc\n+      return _dispatch(req)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 1021, in _dispatch\n+      cmdpats, cmdoptions)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 756, in runcommand\n+      ret = _runcommand(ui, options, cmd, d)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 1030, in _runcommand\n+      return cmdfunc()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 1018, in <lambda>\n+      d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/util.py\", line 1682, in check\n+      return func(*args, **kwargs)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/commands.py\", line 4667, in push\n+      opargs=opargs)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/exchange.py\", line 570, in push\n+      _pushbundle2(pushop)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/exchange.py\", line 1164, in _pushbundle2\n+      'force': pushop.force,\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/thirdparty\/concurrent\/futures\/_base.py\", line 457, in result\n+      return self.__get_result()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/wireprotov1peer.py\", line 211, in sendcommands\n+      result = fn(**pycompat.strkwargs(args))\n+  TypeError: unbundle() got an unexpected keyword argument 'force'\n+  [1]\n```\n\nCould I get you to take a look? I like where this is going, but I don't have the time at the moment to hunt down the issues in the tests.","author":"durin42","id":"100381","dateCreated":"1568212284","dateModified":"1568212284"},{"type":"comment","comment":"Queued this with lots of content added to the commit message. Thanks!","author":"durin42","id":"100379","dateCreated":"1568211385","dateModified":"1568211385"},{"type":"accept","author":"durin42","id":"100378","dateCreated":"1568211385","dateModified":"1568211385"},{"type":"comment","comment":"Yes, server changed since your last pull, and you override the bookmark without so much as a warning.","author":"idlsoft","id":"100223","dateCreated":"1568053939","dateModified":"1568053939"},{"type":"comment","comment":"Clarifying I understand: this causes pushing a bookmark to fail in what cases that it currently succeeds? I think it's just the case of:\n\n  o 2\n  |  o 1 @\n  o\/ 0\n\nwhen I last pulled, `@` was on 0, and now I'm doing `hg push -B @`, but since my last pull the server advanced `@` to 2, meaning it's a non-linear update. Right?\n\nIf so, I wholeheartedly approve, as this behavior has previously burned me and I think it's well past time we started breaking some compatibility edges on bookmarks to make them actually useful to share.","author":"durin42","id":"100154","dateCreated":"1568043768","dateModified":"1568043768"},{"type":"comment","comment":"I see `--force` as a general \"I know what I'm doing, forget your checks\"  instruction.\nIf it's not, then all the variations would need their own `--force-heads`, `--force-bookmarks`, `--force-*`.\nMay be a bit much.\n\nAs for this being configurable?\nI, personally, don't see a lot of value in the current behavior.\nThere may be a use case, but the default behavior, useful for most users, would be to check it, I think.\n","author":"idlsoft","id":"99537","dateCreated":"1567523430","dateModified":"1567523430"},{"type":"comment","comment":"(just interested in this change, I don't have any power to actually accept it)\n\nInteresting. I've thought of `hg push -B` as forcing the move of the bookmark, and `hg push -r` as not forcing a bookmark move, as that's how they behave (well, mostly).\nI don't know if this is a bug: the intended behavior of `push -B` is not explicitly documented, but it at least appears to be consistent with `hg pull -B`.\nBut if it wasn't for compatibility, the behavior you're trying to implement looks superior: it gives the ability to ensure that a push either moves a bookmark forward or fails, which is clearly useful. We have an extension that makes `hg push -r BOOKMARK` have such a behavior, but the fewer extensions the better.\n\nBut given compatibility constraints, this behavior probably needs to be gated by a config option.\n\nAbout more technical aspects, I have a couple of remarks:\n- the change of behavior would be clearer in the diff if you added the test in a first change, and updated the code in a second change\n- the check should probably live in some combination of `exchange.{_processcompared,_pushb2checkbookmarks}` instead (that's where the \"move forward\" logic for push is right now)\n- using `hg push -f` to overwrite the remote bookmark is not great, because -f forces several completely unrelated things (new heads, removes race checks about bookmarks, something about obsolescence markers and something about phases). No one wants to bypass all these at once. Dedicated force flags seems better, perhaps `hg push --force-bookmark BOOKMARK`, to replicate the current behavior of `hg push -B BOOKMARK`.","author":"valentin.gatienbaron","id":"99521","dateCreated":"1567374841","dateModified":"1567374841"},{"type":"comment","comment":"This is a potential fix for https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6193\nThe actual validation is in `bundle2.handlebookmark`.\nThe rest of the changes are there to pass the `force` parameter.\nI've also made `force` available to hooks. That way one can validate who can and cannot use `--force` on a shared repo.","author":"idlsoft","id":"99421","dateCreated":"1567188167","dateModified":"1567188167"},{"type":"update","diffId":"16341","author":"idlsoft","id":"99417","dateCreated":"1567187687","dateModified":"1567187687"}],"dateCreated":"1567187687","dateModified":"1596747653","status":"Needs Revision"},{"id":"8347","callsign":"HG","title":"encoding: use special dictionary type for env variables on Windows","author":"indygreg","summary":"Environment variables on Windows are case insensitive and Python\ninternally uses a special dict type that normalizes all keys to\nuppercase.\n\nOur custom bytes-based environment variable dict on Windows was\nnot aware of this, leading to failures when looking up lower case\nenvironment variables (such as `http_proxy`).\n\nThis commit introduces a custom dict type that normalizes keys\nto uppercase on Windows. test-http-proxy.t passes after this\nchange, as a lookup of b'http_proxy' now succeeds.\n\nIt's worth noting that Python's behavior with regards to\nnormalizing all environment variables to uppercase is buggy.\nSee https:\/\/bugs.python.org\/issue28824. I preserved Python's\nbehavior for compatibility.","testPlan":"","lineCount":"36","dependsOn":["8346"],"reviewers":["marmoute","baymax"],"ccs":["mercurial-patches","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"132220","dateCreated":"1596218195","dateModified":"1596218195"},{"type":"reject","author":"baymax","id":"132219","dateCreated":"1596218195","dateModified":"1596218195"},{"type":"comment","comment":"Urg, this make me sad, but seems a reasonable way to move forward.","author":"marmoute","id":"126152","dateCreated":"1587148279","dateModified":"1587148279"},{"type":"accept","author":"marmoute","id":"126151","dateCreated":"1587148279","dateModified":"1587148279"},{"type":"update","diffId":"20920","author":"indygreg","id":"124617","dateCreated":"1585531830","dateModified":"1585531830"}],"dateCreated":"1585531830","dateModified":"1596218195","status":"Needs Revision"},{"id":"8345","callsign":"HG","title":"tests: look for CRLF on Windows","author":"indygreg","summary":"The ui.editor code calls util.tonativeeol() to normalize line endings\nto the platform native format. So, editor files may have CRLF\nin them. For some reason, just this one specific test case was\nfailing on Python 3 on Windows. (The output before this change\nwas `...\\r (esc)`, but only on the first line of output. I suspect\nthe test harness output parser was getting confused by the specific\nbyte sequences in this output or something.\n\nI wanted to hack around this by filtering output via sed to remove\nthe CR. But check-code says this practice is apparently banned.\nSo I just made the test conditional.","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":["durin42","marmoute","baymax"],"ccs":["mercurial-patches","marmoute","mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"132216","dateCreated":"1596218194","dateModified":"1596218194"},{"type":"reject","author":"baymax","id":"132215","dateCreated":"1596218194","dateModified":"1596218194"},{"type":"accept","author":"marmoute","id":"126180","dateCreated":"1587153646","dateModified":"1587153646"},{"type":"comment","comment":">>! In D8345#126157, @marmoute wrote:\n> @mharbison72 @indygreg, IIRC Matt is saying this is the wrong fix. What's the status of this?\n\nI'm not sure that it's *wrong*, I'm just wondering if there's an encoding and\/or stdio issue lurking here somewhere.","author":"mharbison72","id":"126175","dateCreated":"1587149990","dateModified":"1587149990"},{"type":"comment","comment":"@mharbison72 @indygreg, IIRC Matt is saying this is the wrong fix. What's the status of this?","author":"marmoute","id":"126157","dateCreated":"1587148399","dateModified":"1587148399"},{"type":"comment","comment":"The test harness *should* match existing `\\n` output as a fallback, which got me to wondering if it was the `(esc)` at the end screwing it up.  I tried this patch:\n\n```\ndiff --git a\/tests\/run-tests.py b\/tests\/run-tests.py\n--- a\/tests\/run-tests.py\n+++ b\/tests\/run-tests.py\n@@ -2065,6 +2065,8 @@ class TTest(Test):\n             if PYTHON3:\n                 el = el[:-7].decode('unicode_escape') + '\\n'\n                 el = el.encode('utf-8')\n+                log('el: %s' % el)\n+                log(' l: %s' % l)\n             else:\n                 el = el[:-7].decode('string-escape') + '\\n'\n         if el == l or os.name == 'nt' and el[:-1] + b'\\r\\n' == l:\n```\n\n... and got this output:\n\n```\n$ time py -3 run-tests.py --local test-histedit-arguments.t#abortflag --view bcompare\nrunning 1 tests using 1 parallel processes\nel: b'pick 3d3ea1f3a10b 5 1234567890123456789012345678901234567890123456789012345\\xc3\\xa3\\xc2\\x81\\xc2\\x82...\\n'\n l: b'pick 3d3ea1f3a10b 5 1234567890123456789012345678901234567890123456789012345\\xe3\\x81\\x82...\\r\\n'\n```\n\nSo I'm not sure where the bytes are being lost.  If this doesn't suggest a larger problem, I've got no problem with this patch as written.  But I wonder if there's some stdio that needs to be patched up, because I thought I saw that pattern in some failing py3 tests at one point.","author":"mharbison72","id":"124639","dateCreated":"1585543859","dateModified":"1585543859"},{"type":"update","diffId":"20918","author":"indygreg","id":"124600","dateCreated":"1585531828","dateModified":"1585531828"}],"dateCreated":"1585531828","dateModified":"1596218194","status":"Needs Revision"},{"id":"8346","callsign":"HG","title":"tests: force newlines to LF in tinyproxy.py","author":"indygreg","summary":"Yet another instance where we need to replace the sys.std* streams\nto prevent CRLF from creeping in on Windows.","testPlan":"","lineCount":"18","dependsOn":["8345"],"reviewers":["marmoute","baymax"],"ccs":["mercurial-patches","mharbison72","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"132212","dateCreated":"1596218192","dateModified":"1596218192"},{"type":"reject","author":"baymax","id":"132211","dateCreated":"1596218192","dateModified":"1596218192"},{"type":"accept","author":"marmoute","id":"126181","dateCreated":"1587153662","dateModified":"1587153662"},{"type":"comment","comment":"actually @mharbison72  comment on D8345 make me reconsider. Please allign the status of this with the status of D8345.","author":"marmoute","id":"126161","dateCreated":"1587148461","dateModified":"1587148461"},{"type":"resign","author":"marmoute","id":"126158","dateCreated":"1587148461","dateModified":"1587148461"},{"type":"comment","comment":"looks legit","author":"marmoute","id":"126155","dateCreated":"1587148303","dateModified":"1587148303"},{"type":"accept","author":"marmoute","id":"126154","dateCreated":"1587148303","dateModified":"1587148303"},{"type":"update","diffId":"20919","author":"indygreg","id":"124609","dateCreated":"1585531829","dateModified":"1585531829"}],"dateCreated":"1585531829","dateModified":"1596218193","status":"Needs Revision"},{"id":"8348","callsign":"HG","title":"tests: force newlines to LF in inline Python script","author":"indygreg","summary":"Like we've done in what seems like an infinite stream of random\nscripts, we need to set sys.stdout to normalize to LF on\nPython 3 on Windows or else CRLF can creep in.\n\nWith this change, test-fix.t now passes on Python 3 on Windows.","testPlan":"","lineCount":"9","dependsOn":["8347"],"reviewers":["marmoute","baymax"],"ccs":["mercurial-patches","mharbison72","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"132208","dateCreated":"1596218191","dateModified":"1596218191"},{"type":"reject","author":"baymax","id":"132207","dateCreated":"1596218191","dateModified":"1596218191"},{"type":"accept","author":"marmoute","id":"126182","dateCreated":"1587153667","dateModified":"1587153667"},{"type":"comment","comment":"actually @mharbison72 comment on D8345 make me reconsider. Please allign the status of this with the status of D8345.","author":"marmoute","id":"126166","dateCreated":"1587148473","dateModified":"1587148473"},{"type":"resign","author":"marmoute","id":"126163","dateCreated":"1587148473","dateModified":"1587148473"},{"type":"comment","comment":"looks legit.","author":"marmoute","id":"126149","dateCreated":"1587148204","dateModified":"1587148204"},{"type":"accept","author":"marmoute","id":"126148","dateCreated":"1587148204","dateModified":"1587148204"},{"type":"update","diffId":"20921","author":"indygreg","id":"124625","dateCreated":"1585531832","dateModified":"1585531832"}],"dateCreated":"1585531832","dateModified":"1596218191","status":"Needs Revision"},{"id":"5496","callsign":"HG","title":"revset: add \"samebranch\" keyword argument to the merge revset","author":"angel.ezquerra","summary":"By default all merges are shown but if \"samebranch\" is set to False then merges\nwith the same branch (i.e. where both parents belong to the same branch) will\nbe filtered out.\n\nConversely, if \"samebranch\" is set to True then only merges with the same branch\nwill be shown.\n\nThis is useful to visualize at a high level the relationships between different\nbranches and how they are merged with each other.\n\nWith the addition of the merge(withbranch) idiom on a previous revision this\ncould already be done in a quite complicated way, by doing something like:\n\nmerge() and branch(somebranch) and not merge(somebranch)\n\nThis is not very practical ano only works for a single branch. Thus this new\noption is added.","testPlan":"","lineCount":"59","dependsOn":["5495"],"reviewers":["baymax"],"ccs":["mercurial-patches","marmoute","mharbison72","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"132205","dateCreated":"1596218190","dateModified":"1596218190"},{"type":"reject","author":"baymax","id":"132204","dateCreated":"1596218190","dateModified":"1596218190"},{"type":"comment","comment":"Gentle ping on this series, the feature sounds interesting.","author":"marmoute","id":"126445","dateCreated":"1587571245","dateModified":"1587571287"},{"type":"comment","comment":"Maybe we should not try to use boolean. we could have\n\n`merge(parentbranches=\"same\")`\n\nwith the possible value being: `same`, `different`, `any` (an possibly some constains about `branch(p1(x)) == branch(x)`","author":"marmoute","id":"117278","dateCreated":"1579799198","dateModified":"1579799198"},{"type":"comment","comment":">   Maybe `anonymous`, defaulting to True?\n\nTo all: the default can't be True. It would break the current `merge()`\nrevset behavior. Only viable choice is to set the default to \"don't care\".\n\nAnd I think tri-state bool is confusing in this context. So, IMHO, it's\nbetter to add an argument taking a keyword string specifying constraint\nsuch as `merge(between=\"a-keyword-to-select-merges-of-named-branches\")`.\n\n> That's in the glossary under `Branch, anonymous`, so not technically\n> a merge, but I think it still conveys the point.\n\nI disagree. Merges of the same branch are pretty common if your team preferred\nmerge-based strategy. I wouldn't explicitly call new head pulled from public\nrepo as an anonymous head.\n\nIt can also be wrong if you're using bookmarks.","author":"yuja","id":"83416","dateCreated":"1548247882","dateModified":"1548247882"},{"type":"comment","comment":">>! In D5496#82908, @angel.ezquerra wrote:\n>>>! In D5496#82671, @yuja wrote:\n> \n> Do you mean that the flag should only indicate whether you want to hide the same branch merges? I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps \"hidesame\"? Or \"includesame\" or \"includeself\", defaulting to True? Any ideas?\n\nMaybe `anonymous`, defaulting to True?  That's in the glossary under `Branch, anonymous`, so not technically a merge, but I think it still conveys the point.\n\nI think I have a similar reaction as Yuya, but in the opposite direction- `merge(anonymous=True)` makes me think that's all that's of interest.  So maybe `withanonymous`?\n\nI do like the compactness of:\n\n    merge() => all merges\n    merge(anonymous=True) => only merges with matching (p1, p2) branch names\n    merge(anonymous=False) => only merges with different (p1, p2) branch names\n\nOtherwise finding only anonymous merges is something like `merge() - merge(anonymous=False)`, and it took some thinking to get there with the double negative.\n\nBut I have no idea how well that applies to other things if we set that precedent here, and don't feel that strongly about it.","author":"mharbison72","id":"83200","dateCreated":"1548181703","dateModified":"1548181703"},{"type":"comment","comment":">   > Okay, I didn't notice that. And it's tricky to map `samebranch=False` to\n>   >  \"different branch\" constraint. I would read it as \"I don't care whether\n>   >  the branches are the same or not.\"\n>   >\n>   > We can instead express it as `merge() - merge(samebranch=True)`.\n>   \n>   Do you mean that the flag should only indicate whether you want to hide the same branch merges?\n\nI just mean tri-state bool is confusing. `<whatever>=False` sounds like we\ndon't care about the `<whatever>` condition.\n\n> I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps \"hidesame\"? Or \"includesame\" or \"includeself\", defaulting to True? Any ideas?\n\nIt could be an argument taking a string like `'same'`, but I can't think\nof nice names. What's the best term describing a merge between two named\nbranches?","author":"yuja","id":"83052","dateCreated":"1547734900","dateModified":"1547734900"},{"type":"comment","comment":">>! In D5496#82671, @yuja wrote:\n>>   > `[, samebranch]` or [, samebranch=False]`.\n>>   \n>>   I guess that means:\n>>   \n>>   @predicate('merge([withbranch [, samebranch=None]])', safe=True)\n>>   \n>>   Right? (I realized that it is incorrect to say that samebranch's default value is False).\n> \n> Okay, I didn't notice that. And it's tricky to map `samebranch=False` to\n> \"different branch\" constraint. I would read it as \"I don't care whether\n> the branches are the same or not.\"\n\n>>! In D5496#82671, @yuja wrote:\n>>   > `[, samebranch]` or [, samebranch=False]`.\n>>   \n>>   I guess that means:\n>>   \n>>   @predicate('merge([withbranch [, samebranch=None]])', safe=True)\n>>   \n>>   Right? (I realized that it is incorrect to say that samebranch's default value is False).\n> \n> Okay, I didn't notice that. And it's tricky to map `samebranch=False` to\n> \"different branch\" constraint. I would read it as \"I don't care whether\n> the branches are the same or not.\"\n> \n> We can instead express it as `merge() - merge(samebranch=True)`.\n\nDo you mean that the flag should only indicate whether you want to hide the same branch merges? I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps \"hidesame\"? Or \"includesame\" or \"includeself\", defaulting to True? Any ideas?\n","author":"angel.ezquerra","id":"82908","dateCreated":"1547662268","dateModified":"1547662268"},{"type":"comment","comment":">   > `[, samebranch]` or [, samebranch=False]`.\n>   \n>   I guess that means:\n>   \n>   @predicate('merge([withbranch [, samebranch=None]])', safe=True)\n>   \n>   Right? (I realized that it is incorrect to say that samebranch's default value is False).\n\nOkay, I didn't notice that. And it's tricky to map `samebranch=False` to\n\"different branch\" constraint. I would read it as \"I don't care whether\nthe branches are the same or not.\"\n\nWe can instead express it as `merge() - merge(samebranch=True)`.\n\n>   >   if len(matchfns) == 1:\n>   >       # fast path for common case\n>   >       return subset.filter(matchfn[0], ...)\n>   >   else:\n>   >       return subset.filter(lambda r: all(p(r) for p in matchfn), ...)\n>   \n>   Do you think this makes the code simpler?\n\nYes. The original version was hard to find all possible call paths.\nSeparate function per constraint is easier to follow.\n\n> In any case, if you think this approach is best I can do it, but perhaps it would be a little better to keep a single subset.filter call as follows:\n>   \n>     if len(matchfns) == 1:\n>         finalmatchfn = matchfns[0]\n>     else:\n>         finalmatchfn = lambda r: all(p(r) for p in matchfns)\n>     return subset.filter(finalmatchfn, condrepr='<merge>')\n\nI don't care about these differences.","author":"yuja","id":"82671","dateCreated":"1547644201","dateModified":"1547644201"},{"type":"comment","comment":">>! In D5496#82394, @yuja wrote:\n>> -@predicate('merge(withbranch)', safe=True)\n>> +@predicate('merge(withbranch, samebranch=True)', safe=True)\n> \n> `[, samebranch]` or [, samebranch=False]`.\n\nI guess that means:\n\n@predicate('merge([withbranch [, samebranch=None]])', safe=True)\n\nRight? (I realized that it is incorrect to say that samebranch's default value is False).\n\n>>      withbranch = ''\n>>      if 'withbranch' in args:\n>>          withbranch = getstring(args['withbranch'],\n>>                                 _('withbranch argument must be a string'))\n>>          kind, branchname, branchmatcher = stringutil.stringmatcher(withbranch)\n>> +    samebranch = None\n>> +    if 'samebranch' in args:\n>> +        # i18n: \"samebranch\" is a keyword\n>> +        samebranch = getboolean(args['samebranch'],\n>> +            _('samebranch argument must be a True or False'))\n>>      cl = repo.changelog\n>>      # create the function that will be used to filter the subset\n>>      if withbranch:\n>>          # matchfn is a function that returns true when a revision\n>>          # is a merge and the second parent belongs to a branch that\n>>          # matches the withbranch pattern (which can be a literal or a regex)\n>>          if kind == 'literal':\n>> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> -                                 and repo[r].p2().branch() == withbranch)\n>> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> +                                     and repo[r].p2().branch() == withbranch)\n>>          else:\n>> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> -                                 and branchmatcher(repo[r].p2().branch()))\n>> -    else:\n>> -        # matchfn is a function that returns true when a revision is a merge\n>> -        matchfn = lambda r: cl.parentrevs(r)[1] != -1\n>> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> +                                     and branchmatcher(repo[r].p2().branch()))\n>> +    else:\n>> +        basematchfn = lambda r: cl.parentrevs(r)[1] != -1\n>> +    if samebranch is None:\n>> +        matchfn = basematchfn\n>> +    else:\n>> +        # if samebranch was specified, build a new match function\n>> +        # that on top of basematch checks if the parents belong (or not)\n>> +        # to the same branch (depending on the value of samebranch)\n>> +        def matchfn(r):\n>> +            c = repo[r]\n>> +            if not basematchfn(r):\n>> +                return False\n>> +            issamebranchmerge = c.p1().branch() == c.p2().branch()\n>> +            return issamebranchmerge if samebranch else not issamebranchmerge\n> \n> These conditions can be formed as followed:\n> \n> ```\n> matchfns = [lambda r: cl.parentrevs(r)[1] != -1]\n> if withbranch:\n>     matchfns.append(lambda r: branchmatcher(repo[r].p2().branch()))\n> if samebranch:\n>     matchfns.append(samebranchmatchfn)\n> \n> if len(matchfns) == 1:\n>     # fast path for common case\n>     return subset.filter(matchfn[0], ...)\n> else:\n>     return subset.filter(lambda r: all(p(r) for p in matchfn), ...)\n> ```\n\nDo you think this makes the code simpler? In any case, if you think this approach is best I can do it, but perhaps it would be a little better to keep a single subset.filter call as follows:\n\n```\nif len(matchfns) == 1:\n    finalmatchfn = matchfns[0]\nelse:\n    finalmatchfn = lambda r: all(p(r) for p in matchfns)\nreturn subset.filter(finalmatchfn, condrepr='<merge>')\n```\n\nWhat do you think?\n","author":"angel.ezquerra","id":"82562","dateCreated":"1547596927","dateModified":"1547596927"},{"type":"update","diffId":"13211","author":"angel.ezquerra","id":"82415","dateCreated":"1547508409","dateModified":"1547508409"},{"type":"comment","comment":"> -@predicate('merge(withbranch)', safe=True)\n> +@predicate('merge(withbranch, samebranch=True)', safe=True)\n\n`[, samebranch]` or [, samebranch=False]`.\n\n>      withbranch = ''\n>      if 'withbranch' in args:\n>          withbranch = getstring(args['withbranch'],\n>                                 _('withbranch argument must be a string'))\n>          kind, branchname, branchmatcher = stringutil.stringmatcher(withbranch)\n> +    samebranch = None\n> +    if 'samebranch' in args:\n> +        # i18n: \"samebranch\" is a keyword\n> +        samebranch = getboolean(args['samebranch'],\n> +            _('samebranch argument must be a True or False'))\n>      cl = repo.changelog\n>      # create the function that will be used to filter the subset\n>      if withbranch:\n>          # matchfn is a function that returns true when a revision\n>          # is a merge and the second parent belongs to a branch that\n>          # matches the withbranch pattern (which can be a literal or a regex)\n>          if kind == 'literal':\n> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> -                                 and repo[r].p2().branch() == withbranch)\n> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> +                                     and repo[r].p2().branch() == withbranch)\n>          else:\n> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> -                                 and branchmatcher(repo[r].p2().branch()))\n> -    else:\n> -        # matchfn is a function that returns true when a revision is a merge\n> -        matchfn = lambda r: cl.parentrevs(r)[1] != -1\n> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> +                                     and branchmatcher(repo[r].p2().branch()))\n> +    else:\n> +        basematchfn = lambda r: cl.parentrevs(r)[1] != -1\n> +    if samebranch is None:\n> +        matchfn = basematchfn\n> +    else:\n> +        # if samebranch was specified, build a new match function\n> +        # that on top of basematch checks if the parents belong (or not)\n> +        # to the same branch (depending on the value of samebranch)\n> +        def matchfn(r):\n> +            c = repo[r]\n> +            if not basematchfn(r):\n> +                return False\n> +            issamebranchmerge = c.p1().branch() == c.p2().branch()\n> +            return issamebranchmerge if samebranch else not issamebranchmerge\n\nThese conditions can be formed as followed:\n\n```\nmatchfns = [lambda r: cl.parentrevs(r)[1] != -1]\nif withbranch:\n    matchfns.append(lambda r: branchmatcher(repo[r].p2().branch()))\nif samebranch:\n    matchfns.append(samebranchmatchfn)\n\nif len(matchfns) == 1:\n    # fast path for common case\n    return subset.filter(matchfn[0], ...)\nelse:\n    return subset.filter(lambda r: all(p(r) for p in matchfn), ...)\n```","author":"yuja","id":"82395","dateCreated":"1547435478","dateModified":"1547435478"},{"type":"update","diffId":"13205","author":"angel.ezquerra","id":"82389","dateCreated":"1547419525","dateModified":"1547419525"},{"type":"update","diffId":"13018","author":"angel.ezquerra","id":"81361","dateCreated":"1546801412","dateModified":"1546801412"}],"dateCreated":"1546801412","dateModified":"1596218190","status":"Needs Revision"},{"id":"6312","callsign":"HG","title":"branchcache: update the filteredhash if we update the tiprev","author":"pulkit","summary":"We update the tiprev and in next if statement we check whether the branchcache\nis valid or not. If the update of tiprev happens, then definitely\nself.validfor() will return False because filteredhash is old now.\n\nLet's update the filteredhash if we update the tiprev also. This prevents us\nfrom entering the loop where we iter all the heads, and find the tiprev.","testPlan":"","lineCount":"1","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-patches","marmoute","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"132202","dateCreated":"1596218189","dateModified":"1596218189"},{"type":"reject","author":"baymax","id":"132201","dateCreated":"1596218189","dateModified":"1596218189"},{"type":"comment","comment":"reping","author":"marmoute","id":"126454","dateCreated":"1587571582","dateModified":"1587571582"},{"type":"comment","comment":"This seems useful but lingering. @pulkit what's the status of this.","author":"marmoute","id":"117300","dateCreated":"1579800073","dateModified":"1579800073"},{"type":"comment","comment":">          if ntiprev > self.tiprev:\n>              self.tiprev = ntiprev\n>              self.tipnode = cl.node(ntiprev)\n> +            self.filteredhash = scmutil.filteredhash(repo, self.tiprev)\n>  \n>          if not self.validfor(repo):\n>              # cache key are not valid anymore\n\nand update `self.filteredhash` later again, which smells. Instead, shouldn't\nwe check the validity first, and take the fast path only if it was valid?\n\n```\nif self.validfor(repo):  # was valid, can take fast path\n    self.tiprev = ntiprev\n    self.tipnode = cl.node(ntiprev)\nelse:  # bad luck, recompute tiprev\/tipnode\n    ...\nself.filteredhash = scmutil.filteredhash(repo, self.tiprev)\n```","author":"yuja","id":"91967","dateCreated":"1556440717","dateModified":"1556440717"},{"type":"update","diffId":"14927","author":"pulkit","id":"91837","dateCreated":"1556320974","dateModified":"1556320974"}],"dateCreated":"1556320974","dateModified":"1596218189","status":"Needs Revision"},{"id":"8646","callsign":"HG","title":"update: suggest --merge while `hg up` across topo branches","author":"khanchi97","summary":"Before this patch, during `hg up` across topological branches with\ndirty working directory we suggested the user to \"commit or update\n--clean to discard\"\n\nI think suggesting --merge is better than --clean (which discard\nchanges with no backup). We can keep all the three options, but\nprobably then we will have sacrifice length of message.","testPlan":"","lineCount":"18","dependsOn":[],"reviewers":[],"ccs":["marmoute","mjacob","martinvonz","mercurial-patches"],"actions":[{"type":"plan-changes","author":"khanchi97","id":"130915","dateCreated":"1594924854","dateModified":"1594924854"},{"type":"comment","comment":"also: can we move this to \"change planned\" so that it stop showing up in yadda?","author":"marmoute","id":"130693","dateCreated":"1594830668","dateModified":"1594830668"},{"type":"comment","comment":">>! In D8646#129257, @mjacob wrote:\n> I think it would be a good idea to mention both `--clean` and `--merge`, but mentioning only `--merge` is better than mentioning only `--clean`.\n\n+1 on that.\n\nI hope we can get this soon. ","author":"marmoute","id":"130692","dateCreated":"1594830589","dateModified":"1594830589"},{"type":"comment","comment":"I think it would be a good idea to mention both `--clean` and `--merge`, but mentioning only `--merge` is better than mentioning only `--clean`.","author":"mjacob","id":"129257","dateCreated":"1592917202","dateModified":"1592917202"},{"type":"comment","comment":">>! In D8646#129176, @martinvonz wrote:\n> We have not made this change before because there is no `hg update --abort`. Do we have that feature yet (I haven't followed all the changes recently)?\n\nAh, okay. I see. No, we don't have that feature yet. I sent a patch for `hg update --abort` but I got stuck in a subrepo case where we can lose some changes. I think now I am gonna revisit that case again, and try to figure out the fix or will start a discussion on that. Thanks :)\n(both of these have some discussion on it https:\/\/phab.mercurial-scm.org\/D7786 https:\/\/phab.mercurial-scm.org\/D6735)","author":"khanchi97","id":"129178","dateCreated":"1592806928","dateModified":"1592806928"},{"type":"comment","comment":"We have not made this change before because there is no `hg update --abort`. Do we have that feature yet (I haven't followed all the changes recently)?","author":"martinvonz","id":"129176","dateCreated":"1592802286","dateModified":"1592802286"},{"type":"update","diffId":"21674","author":"khanchi97","id":"129170","dateCreated":"1592791949","dateModified":"1592791949"}],"dateCreated":"1592791949","dateModified":"1594924854","status":"Changes Planned"},{"id":"8616","callsign":"HG","title":"merge: chain copies with existing copies in working copy","author":"martinvonz","summary":"This makes the merge code chain and filter copies when grafting with\ncopies already in the working copy. For example, if the working copy\nhas renamed file A to B and you somehow graft in a change that renames\nB to C, then that will now become a rename from A to C.  That will\nsoon be necessary for `hg rebase --collapse`. It seems that we don't\nhave any existing cases where chaining makes a difference.","testPlan":"","lineCount":"16","dependsOn":["8595"],"reviewers":[],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"inline","comment":"Ah, I see. See `copies.filter()` (called `copies._filter()` at head) for details.","replyTo":"130830","isNewFile":"1","line":"1916","lineLength":"5","path":"mercurial\/merge.py","diffId":"21564","author":"martinvonz","id":"130852","dateCreated":"1594913281","dateModified":"1594913281"},{"type":"comment","comment":"Changes planned to earlier patch in the series","author":"martinvonz","id":"130840","dateCreated":"1594913028","dateModified":"1594913028"},{"type":"plan-changes","author":"martinvonz","id":"130839","dateCreated":"1594913028","dateModified":"1594913028"},{"type":"inline","comment":"Previously, theses extra `ifs` clause were not necessary, Now they appears. Why do they become necessary now ?","replyTo":"130688","isNewFile":"1","line":"1916","lineLength":"5","path":"mercurial\/merge.py","diffId":"21564","author":"marmoute","id":"130830","dateCreated":"1594910013","dateModified":"1594910013"},{"type":"inline","comment":"I guess I don't understand what your question was in that case. Can you rephrase it?","replyTo":"130677","isNewFile":"1","line":"1916","lineLength":"5","path":"mercurial\/merge.py","diffId":"21564","author":"martinvonz","id":"130688","dateCreated":"1594830155","dateModified":"1594830155"},{"type":"inline","comment":"I don't understand how it answser my question of \"why does these new cases pops up?\"","replyTo":"128874","isNewFile":"1","line":"1916","lineLength":"5","path":"mercurial\/merge.py","diffId":"21564","author":"marmoute","id":"130677","dateCreated":"1594829934","dateModified":"1594829934"},{"type":"comment","comment":"(I have an unsubmitted question laying around for over a month\u2026)","author":"marmoute","id":"130676","dateCreated":"1594829934","dateModified":"1594829934"},{"type":"update","diffId":"21608","author":"martinvonz","id":"128876","dateCreated":"1591886052","dateModified":"1591886052"},{"type":"inline","comment":"Did you miss the comment I added on line 1914 or do you think it's not enough? Each case is documented there.","replyTo":"128870","isNewFile":"1","line":"1916","lineLength":"5","path":"mercurial\/merge.py","diffId":"21564","author":"martinvonz","id":"128874","dateCreated":"1591883475","dateModified":"1591883475"},{"type":"inline","comment":"I am not sure why we gain all these new cases? where do they comes from?","replyTo":null,"isNewFile":"1","line":"1916","lineLength":"5","path":"mercurial\/merge.py","diffId":"21564","author":"marmoute","id":"128870","dateCreated":"1591883145","dateModified":"1591883145"},{"type":"update","diffId":"21605","author":"martinvonz","id":"128857","dateCreated":"1591811649","dateModified":"1591811649"},{"type":"comment","comment":">>! In D8616#128712, @marmoute wrote:\n> This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?\n\nThat was on an earlier version of the series; this series is now ready.","author":"martinvonz","id":"128752","dateCreated":"1591711917","dateModified":"1591711917"},{"type":"comment","comment":"This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?","author":"marmoute","id":"128712","dateCreated":"1591699657","dateModified":"1591699657"},{"type":"update","diffId":"21564","author":"martinvonz","id":"128515","dateCreated":"1591407542","dateModified":"1591407542"}],"dateCreated":"1591407542","dateModified":"1594913281","status":"Changes Planned"},{"id":"8599","callsign":"HG","title":"rebase: remove now-unused arguments from rebasenode()","author":"martinvonz","summary":"`rebasenode()` is now finally as simple as I think it should be, and\nrebasing is now repeated grafting.","testPlan":"","lineCount":"14","dependsOn":["8598"],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"Changes planned to earlier patch in the series","author":"martinvonz","id":"130850","dateCreated":"1594913080","dateModified":"1594913080"},{"type":"plan-changes","author":"martinvonz","id":"130849","dateCreated":"1594913080","dateModified":"1594913080"},{"type":"accept","author":"marmoute","id":"128863","dateCreated":"1591811948","dateModified":"1591811948"},{"type":"comment","comment":">>! In D8599#128724, @marmoute wrote:\n> This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?\n\nThat was on an earlier version of the series; this series is now ready.","author":"martinvonz","id":"128755","dateCreated":"1591711962","dateModified":"1591711962"},{"type":"comment","comment":"This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?","author":"marmoute","id":"128724","dateCreated":"1591699668","dateModified":"1591699668"},{"type":"update","diffId":"21567","author":"martinvonz","id":"128529","dateCreated":"1591407581","dateModified":"1591407581"},{"type":"update","diffId":"21528","author":"martinvonz","id":"128312","dateCreated":"1590767873","dateModified":"1590767873"}],"dateCreated":"1590767873","dateModified":"1594913080","status":"Changes Planned"},{"id":"8598","callsign":"HG","title":"rebase: drop duplicate call to copies.graftcopies()","author":"martinvonz","summary":"`merge.graft()` already calls it.","testPlan":"","lineCount":"8","dependsOn":["8597"],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"Changes planned to earlier patch in the series","author":"martinvonz","id":"130848","dateCreated":"1594913069","dateModified":"1594913069"},{"type":"plan-changes","author":"martinvonz","id":"130847","dateCreated":"1594913069","dateModified":"1594913069"},{"type":"accept","author":"marmoute","id":"128862","dateCreated":"1591811886","dateModified":"1591811886"},{"type":"comment","comment":">>! In D8598#128720, @marmoute wrote:\n> This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?\n\nThat was on an earlier version of the series; this series is now ready.","author":"martinvonz","id":"128754","dateCreated":"1591711949","dateModified":"1591711949"},{"type":"comment","comment":"This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?","author":"marmoute","id":"128720","dateCreated":"1591699664","dateModified":"1591699664"},{"type":"update","diffId":"21566","author":"martinvonz","id":"128527","dateCreated":"1591407579","dateModified":"1591407579"},{"type":"update","diffId":"21527","author":"martinvonz","id":"128304","dateCreated":"1590767872","dateModified":"1590767872"}],"dateCreated":"1590767872","dateModified":"1594913069","status":"Changes Planned"},{"id":"8596","callsign":"HG","title":"merge: mark copies in in-memory context when merging","author":"martinvonz","summary":"Until now, `merge.update()` didn't mark copies in the\n`overlayworkingctx` (when using that). That's because we copies are\nrecorded in the `wctx` (whether that's a `workingctx` or a\n`overlayworkingctx`) in `recordupdates()`, which is not called when we\nshould not udpate the dirstate, which we should not do for in-memory\nupdates.\n\nWe had not noticed this before because rebase calls graftcopies\nafter. However, I think that using `merge.update()` with an in-memory\ncontext outside the context of rebase would lose copies.\n\nThis patch fixes the problem by first extracting the desired copies\nfrom the `action` map and then applying the changes outside of\n`recordupdates()` (and removing the copy-marking from that method).\n\nAn alternative solution would be to call `recordupdates()` also in the\nin-memory case by modifying it to call `wctx.drop()` etc (which don't\nyet exist), but that would mean that we would add a bunch of no-op\nmethods on `overlayworkingctx`, since that already knows which files\nare tracked.","testPlan":"","lineCount":"57","dependsOn":[],"reviewers":["marmoute"],"ccs":["marmoute","durin42","mercurial-patches"],"actions":[{"type":"comment","comment":">>! In D8596#130836, @martinvonz wrote:\n>>>! In D8596#130831, @marmoute wrote:\n>> Can you mark them as \"changes planned\" in the mean time to clear up yadda?\n> \n> There are no actual changes planned and I guess I figured that the base patch being marked as \"changes planned\" would be sufficient, so sure, I'll update the other ones to that status too.\n\nMy main goal here is to prevent yadda to be over 50% of content to review that is actually not to review.","author":"marmoute","id":"130846","dateCreated":"1594913062","dateModified":"1594913062"},{"type":"comment","comment":">>! In D8596#130831, @marmoute wrote:\n> Can you mark them as \"changes planned\" in the mean time to clear up yadda?\n\nThere are no actual changes planned and I guess I figured that the base patch being marked as \"changes planned\" would be sufficient, so sure, I'll update the other ones to that status too.","author":"martinvonz","id":"130836","dateCreated":"1594912986","dateModified":"1594912986"},{"type":"comment","comment":"Can you mark them as \"changes planned\" in the mean time to clear up yadda?\n","author":"marmoute","id":"130831","dateCreated":"1594910086","dateModified":"1594910086"},{"type":"comment","comment":">>! In D8596#130671, @marmoute wrote:\n> What's the conclusion here ? I feel like we decided to move in the opposite direction\n\nYes, I agree that we should make `recordupdates()` also record copies. I'll update this patch to do that eventually :)\n\n> (and to drop this series).   Is that right ?\n\nMost if the series would still be unchanged, I think. I could drop this patch and replace it by another patch, but I could also reuse the Phabricator review for the new purpose. Doesn't matter much to me.","author":"martinvonz","id":"130686","dateCreated":"1594830058","dateModified":"1594830058"},{"type":"comment","comment":"What's the conclusion here ? I feel like we decided to move in the opposite direction (and to drop this series).   Is that right ?","author":"marmoute","id":"130671","dateCreated":"1594829778","dateModified":"1594829778"},{"type":"inline","comment":"Yes, I was also feeling that more and more. We should probably replicate many dirstate methods on workingctx and its subclasses.","replyTo":"128913","isNewFile":"1","line":"766","lineLength":"0","path":"mercurial\/mergestate.py","diffId":"21560","author":"martinvonz","id":"128916","dateCreated":"1591897642","dateModified":"1591897642"},{"type":"plan-changes","author":"martinvonz","id":"128914","dateCreated":"1591897642","dateModified":"1591897642"},{"type":"inline","comment":"Okay, then it feel like we are going the in wrong direction and breaking the API contract here. For example, why is only part of record update move to apply update ? Does this impact our ability to execute applyupdates in parallel ? etc.\n\nIt would seems much cleaner to call recordupdates on all ctx types, don't it?","replyTo":"128879","isNewFile":"1","line":"766","lineLength":"0","path":"mercurial\/mergestate.py","diffId":"21560","author":"marmoute","id":"128913","dateCreated":"1591897156","dateModified":"1591897156"},{"type":"inline","comment":"Yes, that is correct about their roles. See commit message for my reasoning.","replyTo":"128872","isNewFile":"1","line":"766","lineLength":"0","path":"mercurial\/mergestate.py","diffId":"21560","author":"martinvonz","id":"128879","dateCreated":"1591886113","dateModified":"1591886113"},{"type":"inline","comment":"Good question!  I've added a comment.","replyTo":"128871","isNewFile":"1","line":"1891","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"martinvonz","id":"128878","dateCreated":"1591886113","dateModified":"1591886113"},{"type":"update","diffId":"21607","author":"martinvonz","id":"128875","dateCreated":"1591886050","dateModified":"1591886050"},{"type":"inline","comment":"Okay, so why do we have both a `applyupdates` and `recordupdates` function ? What are their respective resonsability and why is it split ?\n\nIs it that `apply` is only responsible for touching the disk content and `record` to only update internal metadata like the dirstate ? If so, moving the copies recording out of recordupdates seems wrong. ","replyTo":null,"isNewFile":"1","line":"766","lineLength":"0","path":"mercurial\/mergestate.py","diffId":"21560","author":"marmoute","id":"128872","dateCreated":"1591883159","dateModified":"1591883159"},{"type":"inline","comment":"Actually, thinking more about it, I still don't know why we should overlook rename information when overwriting. Can you clarify that point  in a comment ?","replyTo":"128864","isNewFile":"1","line":"1891","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"marmoute","id":"128871","dateCreated":"1591883159","dateModified":"1591883159"},{"type":"inline","comment":"no, phabricator diffing made me think we were in the following function, that takes it as an argument:\n\n```\ndef applyupdates(\n    repo, actions, wctx, mctx, overwrite, wantfiledata, labels=None\n):\n```","replyTo":"128859","isNewFile":"1","line":"1891","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"marmoute","id":"128864","dateCreated":"1591812212","dateModified":"1591812212"},{"type":"inline","comment":"It's defined on line 1631 and used a few times thereafter. Would you like a comment in each place it's used? I can add that in a separate patch. I don't know think there's a relevant docstring to update.","replyTo":"128848","isNewFile":"1","line":"1891","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"martinvonz","id":"128859","dateCreated":"1591811656","dateModified":"1591811656"},{"type":"inline","comment":"> I don't understand this docstring. From what I see of the code, it mostly pull things from an actions dictionnary to put them in a copies dictionnary. That does not seems to involves the dirstates nor any \"recording\". Am I missing something ?\n\nI suspect that all you're missing is https:\/\/www.mercurial-scm.org\/repo\/hg\/file\/61719b9658b1\/mercurial\/mergestate.py#l758 (or maybe you just didn't infer that this was a bad copy from there) :) Fixed.\n\n","replyTo":"128847","isNewFile":"1","line":"1170","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"martinvonz","id":"128858","dateCreated":"1591811656","dateModified":"1591811656"},{"type":"update","diffId":"21603","author":"martinvonz","id":"128854","dateCreated":"1591811647","dateModified":"1591811647"},{"type":"inline","comment":"I don't know what `overwrite` means and the docstring does not mention it. Can you clarify this and fix the docstring ?","replyTo":null,"isNewFile":"1","line":"1891","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"marmoute","id":"128848","dateCreated":"1591810809","dateModified":"1591810809"},{"type":"inline","comment":"I don't understand this docstring. From what I see of the code, it mostly pull things from an actions dictionnary to put them in a copies dictionnary. That does not seems to involves the dirstates nor any \"recording\". Am I missing something ?","replyTo":null,"isNewFile":"1","line":"1170","lineLength":"0","path":"mercurial\/merge.py","diffId":"21560","author":"marmoute","id":"128847","dateCreated":"1591810809","dateModified":"1591810809"},{"type":"comment","comment":"I have a bunch a questions.","author":"marmoute","id":"128846","dateCreated":"1591810809","dateModified":"1591810809"},{"type":"comment","comment":">>! In D8596#128758, @marmoute wrote:\n>>>! In D8596#128750, @martinvonz wrote:\n>>>>! In D8596#128704, @marmoute wrote:\n>>>>>! In D8596#128319, @martinvonz wrote:\n>>>> This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.\n>>> \n>>> Can you add a RFC tag to this then ?\n>> \n>> I had marked it \"Changes Planned\" but I've fixed the issues and the version I uploaded a day or two ago is ready for review .\n> \n> Okay, (It would help if you reply to your own comment to state this clearly, which you now did)\n\nYep, I definitely should have. Sorry that I didn't think of doing that.\n","author":"martinvonz","id":"128759","dateCreated":"1591718787","dateModified":"1591718787"},{"type":"comment","comment":">>! In D8596#128750, @martinvonz wrote:\n>>>! In D8596#128704, @marmoute wrote:\n>>>>! In D8596#128319, @martinvonz wrote:\n>>> This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.\n>> \n>> Can you add a RFC tag to this then ?\n> \n> I had marked it \"Changes Planned\" but I've fixed the issues and the version I uploaded a day or two ago is ready for review .\n\nOkay, (It would help if you reply to your own comment to state this clearly, which you now did)","author":"marmoute","id":"128758","dateCreated":"1591717689","dateModified":"1591717727"},{"type":"comment","comment":">>! In D8596#128704, @marmoute wrote:\n>>>! In D8596#128319, @martinvonz wrote:\n>> This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.\n> \n> Can you add a RFC tag to this then ?\n\nI had marked it \"Changes Planned\" but I've fixed the issues and the version I uploaded a day or two ago is ready for review .","author":"martinvonz","id":"128750","dateCreated":"1591711464","dateModified":"1591711464"},{"type":"request-review","author":"martinvonz","id":"128748","dateCreated":"1591711464","dateModified":"1591711464"},{"type":"comment","comment":">>! In D8596#128319, @martinvonz wrote:\n> This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.\n\nCan you add a RFC tag to this then ?","author":"marmoute","id":"128704","dateCreated":"1591699544","dateModified":"1591699544"},{"type":"reject","author":"marmoute","id":"128703","dateCreated":"1591699544","dateModified":"1591699544"},{"type":"update","diffId":"21560","author":"martinvonz","id":"128497","dateCreated":"1591407457","dateModified":"1591407457"},{"type":"comment","comment":"This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.","author":"martinvonz","id":"128320","dateCreated":"1590768016","dateModified":"1590768016"},{"type":"plan-changes","author":"martinvonz","id":"128318","dateCreated":"1590768016","dateModified":"1590768016"},{"type":"update","diffId":"21525","author":"martinvonz","id":"128289","dateCreated":"1590767870","dateModified":"1590767870"}],"dateCreated":"1590767870","dateModified":"1594913062","status":"Changes Planned"},{"id":"8597","callsign":"HG","title":"rebase: use merge.graft() instead of merge.update()","author":"martinvonz","summary":"It's been possible to call `merge.graft()` here for a while (I don't\nremember which of my previous changes made it possible), but it would\nhave meant that we did a redundant `graftcopies()` call. With the fix\nto make `merge.update()` record copies in the overlayworkingctx (when\nusing that), we can now also remove the redundant `graftcopies()`\ncall. The next patch will do that.","testPlan":"","lineCount":"14","dependsOn":["8616"],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"Changes planned to earlier patch in the series","author":"martinvonz","id":"130845","dateCreated":"1594913055","dateModified":"1594913055"},{"type":"plan-changes","author":"martinvonz","id":"130844","dateCreated":"1594913055","dateModified":"1594913055"},{"type":"reclaim","author":"martinvonz","id":"130843","dateCreated":"1594913047","dateModified":"1594913047"},{"type":"comment","comment":"Changes planned to earlier patch in the series","author":"martinvonz","id":"130842","dateCreated":"1594913039","dateModified":"1594913039"},{"type":"abandon","author":"martinvonz","id":"130841","dateCreated":"1594913039","dateModified":"1594913039"},{"type":"comment","comment":"Great.","author":"marmoute","id":"128861","dateCreated":"1591811694","dateModified":"1591811694"},{"type":"accept","author":"marmoute","id":"128860","dateCreated":"1591811694","dateModified":"1591811694"},{"type":"comment","comment":">>! In D8597#128716, @marmoute wrote:\n> This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?\n\nThat was on an earlier version of the series; this series is now ready.","author":"martinvonz","id":"128753","dateCreated":"1591711931","dateModified":"1591711931"},{"type":"comment","comment":"This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?","author":"marmoute","id":"128716","dateCreated":"1591699660","dateModified":"1591699660"},{"type":"update","diffId":"21565","author":"martinvonz","id":"128522","dateCreated":"1591407577","dateModified":"1591407577"},{"type":"update","diffId":"21526","author":"martinvonz","id":"128297","dateCreated":"1590767871","dateModified":"1590767871"}],"dateCreated":"1590767871","dateModified":"1594913055","status":"Changes Planned"},{"id":"8595","callsign":"HG","title":"copies: make _chain() and _filter() public","author":"martinvonz","summary":"The next patch will add a call to chain(). I made _filter() public\njust for consistency.","testPlan":"","lineCount":"18","dependsOn":["8596"],"reviewers":["indygreg"],"ccs":["marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"Changes planned to earlier patch in the series","author":"martinvonz","id":"130838","dateCreated":"1594913019","dateModified":"1594913019"},{"type":"plan-changes","author":"martinvonz","id":"130837","dateCreated":"1594913019","dateModified":"1594913019"},{"type":"update","diffId":"21604","author":"martinvonz","id":"128856","dateCreated":"1591811648","dateModified":"1591811648"},{"type":"comment","comment":">>! In D8595#128708, @marmoute wrote:\n> This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?\n\nThat was on an earlier version of the series; this series is now ready.","author":"martinvonz","id":"128751","dateCreated":"1591711898","dateModified":"1591711898"},{"type":"comment","comment":"This patch seems related to D8596 which @martinvonz pointed as \"not meant to be merged\". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?","author":"marmoute","id":"128708","dateCreated":"1591699645","dateModified":"1591699645"},{"type":"update","diffId":"21561","author":"martinvonz","id":"128502","dateCreated":"1591407458","dateModified":"1591407458"},{"type":"accept","author":"indygreg","id":"128346","dateCreated":"1590855643","dateModified":"1590855643"},{"type":"update","diffId":"21524","author":"martinvonz","id":"128284","dateCreated":"1590767868","dateModified":"1590767868"}],"dateCreated":"1590767868","dateModified":"1594913019","status":"Changes Planned"},{"id":"6876","callsign":"HG","title":"phabricator: support automatically obsoleting old revisions of pulled commits","author":"mharbison72","summary":"This is basically an import of the `pullcreatemarkers` extension[1] from the FB\nrepo, with minor adjustments to `getmatchingdiff()` to work with modern hg.\nSince this is very phabricator specific, it makes more sense to me to bundle it\ninto the existing extension.  It wasn't very obvious from the old name what\nfunctionality was provided, and it may make sense to do this in other scenarios\nbesides `hg pull`.\n\nThere are two use cases that I can see- first, ensuring that old revisions are\ncleaned up for a contributor (I seem to recall something I submitted recently\nneeded to be explicitly pruned, though most submissions do clean up\nautomatically).  Second, any `hg phabread | hg import -` would otherwise need to\nbe manually cleaned up.  The latter is annoying enough that I tend not to grab\nthe code and try it when reviewing.\n\nIt is currently guarded by a config option (off by default), because @marmoute\nexpressed concerns about duplicate marker creation if the pushing reviewer also\ncreates a marker.  I don't think that's possible here, since the obsolete\nrevisions are explicitly excluded.  But maybe there are other reasons someone\nwouldn't want older revisions obsoleted.  The config name reflects the fact that\nI'm not sure if other things like import should get this too.\n\nI suspect that we could wrap a function deeper in the pull sequence to improve\nboth the code and the UX.  For example, when pulling an obsolete marker, it can\nprint out a warning that the working directory parent is obsolete, but that\ndoesn't happen here.  (It won't happen with this test.  It *should* without the\n`--bypass` option, but doesn't.)  It should also be possible to not have to\nquery the range of new revisions, and maybe it can be added to the existing\ntransaction.\n\n[1] https:\/\/bitbucket.org\/facebook\/hg-experimental\/src\/default\/hgext3rd\/pullcreatemarkers.py","testPlan":"","lineCount":"69","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-patches","pulkit","sheehan","Kwan","mercurial-devel","marmoute"],"actions":[{"type":"plan-changes","author":"mharbison72","id":"130697","dateCreated":"1594833808","dateModified":"1594833808"},{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117510","dateCreated":"1579887103","dateModified":"1579887103"},{"type":"reject","author":"baymax","id":"117509","dateCreated":"1579887103","dateModified":"1579887103"},{"type":"inline","comment":"Right, and this is probably the typical case. (The `phabimport` alias I have imports as secret to prevent accidental push.)  But secret is visible to the user, and benefits from the cleanup.  Archived isn\u2019t visible (IIUC), so it probably doesn\u2019t need to be obsoleted too- especially if we\u2019re worried about marker growth.\n\n(I\u2019m also not sure how well thg handles archived, and that probably needs to be squared away first if we opt to archive instead of obsolete here.)","replyTo":"102970","isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102982","dateCreated":"1570536765","dateModified":"1570536765"},{"type":"inline","comment":"I see. So maybe this should only obsolete things that have no precursors, and warn (and ignore) things that do.  That means it doesn\u2019t clean up if the reviewer accidentally forgets to import with `\u2014obsolete`, but that\u2019s easy enough to fix with a copy\/paste command if A and A' are identified in the output.","replyTo":"102971","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102981","dateCreated":"1570536765","dateModified":"1570536765"},{"type":"inline","comment":"User  A phasend a patch\n\n  - User A phasend a changeset `A` as D1337\n  - User B phabimport D1337, rebase (as `A'`) and pushes\n  - User A fix critical bug in D1337 and amend it as `A''`\n  - User A pull the **old** version of D1337 without the fix.\n\nIf we obsolete the **new** version of D1337 (`A''`), we are silently dropping the fix to the critical bug.\n\nIf markers were properly exchange, the evolution machinery would detect the divergence, warn the user and be able to automatically solve it. Preserving the fix to the criticial bug.\n\n","replyTo":"102947","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102971","dateCreated":"1570529823","dateModified":"1570529823"},{"type":"inline","comment":"Thing could be in `secret` phase too.","replyTo":"102944","isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102970","dateCreated":"1570529823","dateModified":"1570529823"},{"type":"inline","comment":"I do mean **after** locking (sorry)","replyTo":"102945","isNewFile":"1","line":"225","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102969","dateCreated":"1570529823","dateModified":"1570529823"},{"type":"inline","comment":"It looks like, based on the loop where it's used, it will obsolete \/\/all\/\/ (non public) commits that match.  The only way I can think of where that happens is if I `phabimport` someone else's patches, they make updates, and then I `phabimport` again.  That's why I was wondering aloud about doing this on import, but if the eventual pull cleans it all up, that may be sufficient for the use case I had in mind.  I don't see how a developer would do that on their own commits with amend and friends.\n\nDo you have any ideas to detect phase divergence?  And can that even happen if we're ignoring public commits?","replyTo":"102927","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102947","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"I wonder if it would be better in some txn hook.  And then it could (I think) share the existing transaction and lock.","replyTo":"102929","isNewFile":"1","line":"192","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102946","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"You mean \/\/after\/\/ locking, correct?","replyTo":"102928","isNewFile":"1","line":"225","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102945","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"Agreed.\n\nI saw mention of the archived phase the other day; how would that (and other special phases) play here?","replyTo":"102926","isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102944","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"comment","comment":">>! In D6876#102925, @marmoute wrote:\n> The feature seens pretty usful, but is also a potential foot-gun\/data-loss engine. I think it is useful to take the feature, but maybe with proper documentaiton warning and turned of by efaut. I made a couple of comment about the implementation.\n\nI basically agree with the inline comments.  This was an import with minimal changes as a baseline, and I didn't want to spend time making a bunch of follow ups until I gauged interest in this.\n\nAlternately, if there's concern over obsolete marker growth, should this use the archived phase instead?  Since the use case is mostly around stuff a developer imports locally, I don't see much value in those markers being exchangeable.  The only potential hole I see is if someone has pushed this to a non publishing repo before pulling.  Then everyone else could pull the (not obsoleted) commit.  But then \/\/they\/\/ would archive it on pull too, instead of N developers potentially creating N markers for the same commit.","author":"mharbison72","id":"102943","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"It would probably make sense to wrap the pull exchange logic instead. It would catch more instance and could reuse the same transaction.","replyTo":null,"isNewFile":"1","line":"192","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102929","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"inline","comment":"We should do the computation before locking to avoid other process updating the repo under our feet.","replyTo":null,"isNewFile":"1","line":"225","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102928","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"inline","comment":"So, this only checks the diff number, right ? So in theory, we could obsolete a later version of this, silently dropping change (instead of detecting potential phase-divergence)","replyTo":null,"isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102927","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"inline","comment":"This should be `non public()` instead of `draft()` these could be draft.","replyTo":null,"isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102926","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"comment","comment":"The feature seens pretty usful, but is also a potential foot-gun\/data-loss engine. I think it is useful to take the feature, but maybe with proper documentaiton warning and turned of by efaut. I made a couple of comment about the implementation.","author":"marmoute","id":"102925","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"comment","comment":"@sheehan this might be of interest to you.","author":"pulkit","id":"102116","dateCreated":"1570282533","dateModified":"1570282533"},{"type":"update","diffId":"16604","author":"mharbison72","id":"100947","dateCreated":"1569388644","dateModified":"1569388644"}],"dateCreated":"1569388644","dateModified":"1594833808","status":"Changes Planned"},{"id":"7576","callsign":"HG","title":"hg-core: add configparser to library","author":"indygreg","summary":"This commit contains all the changes to the recently-imported\nRust code to make it work with our Rust library and pass our\nlinting tests.\n\nWe rename lib.rs to mod.rs to reflect it being a sub-module instead\nof a full library. We add this module to our lib.rs. We add various\npackage dependencies to Cargo.toml. We make a handful of Rust code\nupdates to reflect the new symbol locations. Finally, we add a\nparser.rs containing the boilerplate for generating a config file\nparser from the spec.pest file.\n\nAs part of adding the dependencies, some versions changed slightly\nfrom the upstream Cargo.toml, as we already had referenced a more\nmodern crate version.","testPlan":"","lineCount":"305","dependsOn":["7582"],"reviewers":["baymax"],"ccs":["mercurial-patches","marmoute","Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"130679","dateCreated":"1594830053","dateModified":"1594830053"},{"type":"reject","author":"baymax","id":"130678","dateCreated":"1594830053","dateModified":"1594830053"},{"type":"comment","comment":"@Alphare What's your current opinion on this diff, can you mark it accepted or request change appropriately ?","author":"marmoute","id":"124052","dateCreated":"1584659236","dateModified":"1584659236"},{"type":"comment","comment":"I'm a little lost on the state of this. It looks like we need to downgrade the required Rust version?","author":"durin42","id":"114846","dateCreated":"1578513514","dateModified":"1578513514"},{"type":"inline","comment":"I know it doesn't matter at all, but the timing of this issue is just too funny not to share: https:\/\/github.com\/tokio-rs\/bytes\/issues\/340","replyTo":"111969","isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18547","author":"Alphare","id":"112098","dateCreated":"1576180674","dateModified":"1576180674"},{"type":"inline","comment":"I wonder about this dependency. It uses 4 `usize` for every slice of bytes, and adds some overhead, albeit minimal, that I am trying to justify.\nAre we looking at reaping the benefits down the line? The crate itself is good quality, maintained by the Tokio people, so I'm not *too* worried about it being pre-1.0, but do we need this? ","replyTo":null,"isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18547","author":"Alphare","id":"111969","dateCreated":"1576140492","dateModified":"1576140492"},{"type":"inline","comment":"\"The current minimum required Rust version is 1.36\". This disqualifies this crate from being used in `hg-core` right now. Good news is that it is supposed to offer improvements over existing `std` types like `Mutex` and the like, so it's nothing that would be hard to replace. \n\nAlso, I've seen complaints online about the lack of benchmarks of `parking_lot` against `std` types to back-up their claims for performance. I have not looked into it myself.","replyTo":null,"isNewFile":"1","line":"19","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18547","author":"Alphare","id":"111455","dateCreated":"1575896446","dateModified":"1575896446"},{"type":"update","diffId":"18547","author":"indygreg","id":"111419","dateCreated":"1575774207","dateModified":"1575774207"},{"type":"update","diffId":"18541","author":"indygreg","id":"111381","dateCreated":"1575759414","dateModified":"1575759414"},{"type":"update","diffId":"18536","author":"indygreg","id":"111341","dateCreated":"1575749872","dateModified":"1575749872"}],"dateCreated":"1575749872","dateModified":"1594830053","status":"Needs Revision"},{"id":"8677","callsign":"HG","title":"heptapod: use basename of tests in skiplist in CI (issue6351)","author":"pulkit","summary":"In heptapod CI we create a skiplist of test-check* and don't want to run in\nother test suites as we have specific test suite for checks. However the\nskiplist was not working fine because we were putting test names in form of\n`tests\/test-check*` in it which does not work with our test runner.\n\nWe get the basename of the file and then put it in skiplist.","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"plan-changes","author":"pulkit","id":"129612","dateCreated":"1593771992","dateModified":"1593771992"},{"type":"update","diffId":"21761","author":"pulkit","id":"129607","dateCreated":"1593771898","dateModified":"1593771898"}],"dateCreated":"1593771898","dateModified":"1593771992","status":"Changes Planned"},{"id":"7786","callsign":"HG","title":"update: add --abort option in hg update command (issue4404)","author":"khanchi97","summary":"Here is, what --abort option is basically doing:\n1) hg resolve --unmark, then\n2) hg resolve --all --tool :local\n3) hg up <original ctx> --tool :local\n\nWhere,\nstep 1) is to mark all the files conflicted as unresolved (marking *all*\nfiles to make sure that it also mark the files which might have been\nresolved by user in meantime)\n\nstep 2) resolve all the conflicting files using `--tool :local`\n\nstep 3) update to the revision where it was checkedout before running the\nhg update, using `--tool :local`\n\nUse of `--tool :local` while updating to old revision (step3) make sure that\nit will not hit merge conflict at the time of update. And since we are using\nthe same tool (:local) as we used at the time of resolution (step2) it makes\nsure that we have exact changes in working directory as it was before IIUC.\n\nAdded tests demonstrate the behaviour of new flag.","testPlan":"","lineCount":"97","dependsOn":[],"reviewers":["mharbison72"],"ccs":["mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"This looks like a respin of D6735.  Can you take a look at my comments in there about subrepos, and incorporate the appropriate tests?  (I also didn't side by side compare the existing tests, so I'm not sure if there are things tested in that revision that aren't tested here.)","author":"mharbison72","id":"114439","dateCreated":"1578121196","dateModified":"1578121196"},{"type":"reject","author":"mharbison72","id":"114437","dateCreated":"1578121196","dateModified":"1578121196"},{"type":"update","diffId":"19034","author":"khanchi97","id":"114431","dateCreated":"1578063940","dateModified":"1578063940"}],"dateCreated":"1578063940","dateModified":"1592806928","status":"Needs Revision"},{"id":"6735","callsign":"HG","title":"update: added support for --abort flag(issue4404)","author":"taapas1128","summary":"This patch adds functionality to abort a conflicted\nupdate. A new function `hg.abortupdate()` is added for\nthe purpose which has a helper function\n`hg._unmarkandresolvelocal()` which deals with the\nconflicts occured.\n\nResults are shown in tests.","testPlan":"","lineCount":"210","dependsOn":[],"reviewers":["durin42","mharbison72"],"ccs":["mercurial-patches","joerg.sonnenberger","khanchi97","durin42","mharbison72","pulkit","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6735#123875, @khanchi97 wrote:\n>>>! In D6735#100642, @mharbison72 wrote:\n>> Here's a case I stumbled upon that is a problem.  It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.\n>> \n>> ```\n>> diff --git a\/tests\/test-subrepo.t b\/tests\/test-subrepo.t\n>> --- a\/tests\/test-subrepo.t\n>> +++ b\/tests\/test-subrepo.t\n>> @@ -1027,10 +1027,38 @@ filesystem (see also issue4583))\n>>    > [extensions]\n>>    > fakedirstatewritetime = $TESTDIR\/fakedirstatewritetime.py\n>>    > EOF\n>> +  $ hg -R repo st -S\n>> +  ? s\/b\n>> +  $ hg -R repo diff -S\n>> +  $ hg -R repo log -r .\n>> +  changeset:   0:c4018e9aea1b\n>> +  user:        test\n>> +  date:        Thu Jan 01 00:00:00 1970 +0000\n>> +  summary:     1\n>> +\n>> +  $ cat repo\/.hgsubstate\n>> +  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n>>    $ hg -R repo update\n>>    b: untracked file differs\n>>    abort: untracked files in working directory differ from files in requested revision (in subrepository \"s\")\n> @mharbison72 I am bit confused here.\n> 1) Since `hg -R repo update` resulted with an abort then why we have dirty working directory now? Isn't transaction rollback worked correctly?\n\nTwo things to keep in mind.\n1) updates aren't transactions\n2) even if they were, a transaction is within *one* repo.\n\nWhen you update with subrepos, you check for dirty from the top, recurse to the bottom, and on the way up you update the subrepo.  So in the simple case of parent repo P and subrepo S, you check P for dirty (recursively), then update S, then update P.  If something goes wrong updating P, S is not rolled back.\n\n> 2) Also if you run `hg status` it says \"To continue: run `hg update .`\" but I don't think it's really a \"continue\", since we are still on the same changeset where we ran the first update command and running `hg update .` won't take us to the changeset we wanted to go.\n\nMaybe it needs to continue if it did a partial checkout?  IDK when the parent in dirstate is updated- before or after all files are checked out.\n\n> 3) I found that for interrupted update (only for some particular kind of interrupted update) we store target node value in `.hg\/updatestate` but I couldn't find where we exactly use that value. I found some code which check if that file exists but not one where we use the value stored in that file.\n\nSorry, I'm not sure about that either.  I'd imagine it's for the --continue case though.  Maybe that isn't fully implemented yet?","author":"mharbison72","id":"123876","dateCreated":"1584398748","dateModified":"1584398748"},{"type":"comment","comment":">>! In D6735#100642, @mharbison72 wrote:\n> Here's a case I stumbled upon that is a problem.  It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.\n> \n> ```\n> diff --git a\/tests\/test-subrepo.t b\/tests\/test-subrepo.t\n> --- a\/tests\/test-subrepo.t\n> +++ b\/tests\/test-subrepo.t\n> @@ -1027,10 +1027,38 @@ filesystem (see also issue4583))\n>    > [extensions]\n>    > fakedirstatewritetime = $TESTDIR\/fakedirstatewritetime.py\n>    > EOF\n> +  $ hg -R repo st -S\n> +  ? s\/b\n> +  $ hg -R repo diff -S\n> +  $ hg -R repo log -r .\n> +  changeset:   0:c4018e9aea1b\n> +  user:        test\n> +  date:        Thu Jan 01 00:00:00 1970 +0000\n> +  summary:     1\n> +\n> +  $ cat repo\/.hgsubstate\n> +  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n>    $ hg -R repo update\n>    b: untracked file differs\n>    abort: untracked files in working directory differ from files in requested revision (in subrepository \"s\")\n@mharbison72 I am bit confused here.\n1) Since `hg -R repo update` resulted with an abort then why we have dirty working directory now? Isn't transaction rollback worked correctly?\n2) Also if you run `hg status` it says \"To continue: run `hg update .`\" but I don't think it's really a \"continue\", since we are still on the same changeset where we ran the first update command and running `hg update .` won't take us to the changeset we wanted to go.\n3) I found that for interrupted update (only for some particular kind of interrupted update) we store target node value in `.hg\/updatestate` but I couldn't find where we exactly use that value. I found some code which check if that file exists but not one where we use the value stored in that file.\n>    [255]\n> +  $ hg -R repo update --abort\n> +  abort: no update in progress\n> +  [255]\n> +  $ hg -R repo diff -S\n> +  diff -r c4018e9aea1b .hgsubstate\n> +  --- a\/.hgsubstate Thu Jan 01 00:00:00 1970 +0000\n> +  +++ b\/.hgsubstate Thu Jan 01 00:00:00 1970 +0000\n> +  @@ -1,1 +1,1 @@\n> +  -f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n> +  +cc505f09a8b2644adffa368adb4abc6f70d07bc0 s\n> +  $ hg -R repo log -r .\n> +  changeset:   0:c4018e9aea1b\n> +  user:        test\n> +  date:        Thu Jan 01 00:00:00 1970 +0000\n> +  summary:     1\n> +\n> +\n>    $ cat >> repo\/.hg\/hgrc <<EOF\n>    > [extensions]\n>    > fakedirstatewritetime = !\n> ```\n> \n> Another good way to induce this .hgsubstate issue is to `hg pull -u` on a repo, where the remote subrepo isn't available.  You don't need http for this- you can just rename the remote subrepo.\n\n","author":"khanchi97","id":"123875","dateCreated":"1584395223","dateModified":"1584395223"},{"type":"comment","comment":"Here's a case I stumbled upon that is a problem.  It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.\n\n```\ndiff --git a\/tests\/test-subrepo.t b\/tests\/test-subrepo.t\n--- a\/tests\/test-subrepo.t\n+++ b\/tests\/test-subrepo.t\n@@ -1027,10 +1027,38 @@ filesystem (see also issue4583))\n   > [extensions]\n   > fakedirstatewritetime = $TESTDIR\/fakedirstatewritetime.py\n   > EOF\n+  $ hg -R repo st -S\n+  ? s\/b\n+  $ hg -R repo diff -S\n+  $ hg -R repo log -r .\n+  changeset:   0:c4018e9aea1b\n+  user:        test\n+  date:        Thu Jan 01 00:00:00 1970 +0000\n+  summary:     1\n+\n+  $ cat repo\/.hgsubstate\n+  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n   $ hg -R repo update\n   b: untracked file differs\n   abort: untracked files in working directory differ from files in requested revision (in subrepository \"s\")\n   [255]\n+  $ hg -R repo update --abort\n+  abort: no update in progress\n+  [255]\n+  $ hg -R repo diff -S\n+  diff -r c4018e9aea1b .hgsubstate\n+  --- a\/.hgsubstate Thu Jan 01 00:00:00 1970 +0000\n+  +++ b\/.hgsubstate Thu Jan 01 00:00:00 1970 +0000\n+  @@ -1,1 +1,1 @@\n+  -f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n+  +cc505f09a8b2644adffa368adb4abc6f70d07bc0 s\n+  $ hg -R repo log -r .\n+  changeset:   0:c4018e9aea1b\n+  user:        test\n+  date:        Thu Jan 01 00:00:00 1970 +0000\n+  summary:     1\n+\n+\n   $ cat >> repo\/.hg\/hgrc <<EOF\n   > [extensions]\n   > fakedirstatewritetime = !\n```\n\nAnother good way to induce this .hgsubstate issue is to `hg pull -u` on a repo, where the remote subrepo isn't available.  You don't need http for this- you can just rename the remote subrepo.","author":"mharbison72","id":"100642","dateCreated":"1568603671","dateModified":"1568603671"},{"type":"comment","comment":"Oops, meant to flag changes needed too.","author":"mharbison72","id":"100435","dateCreated":"1568266462","dateModified":"1568266462"},{"type":"reject","author":"mharbison72","id":"100434","dateCreated":"1568266462","dateModified":"1568266462"},{"type":"comment","comment":">>! In D6735#100392, @durin42 wrote:\n> This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?\n\nI forgot about this, thanks for the reminder.  @taapas1128 is correct- the subrepos aren't being initialized as subrepos (i.e. there's no .hgsub file).  I'll try to play with this more Friday or over the weekend.","author":"mharbison72","id":"100433","dateCreated":"1568266403","dateModified":"1568266403"},{"type":"comment","comment":"@durin42 I don't think the subrepos are properly initialized in the tests. I would be updating them soon.","author":"taapas1128","id":"100416","dateCreated":"1568219239","dateModified":"1568219239"},{"type":"comment","comment":"This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?","author":"durin42","id":"100392","dateCreated":"1568215450","dateModified":"1568215450"},{"type":"accept","author":"durin42","id":"100391","dateCreated":"1568215450","dateModified":"1568215450"},{"type":"inline","comment":"@mharbison72 Have a look. I have updated the diff.","replyTo":"98964","isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"taapas1128","id":"99147","dateCreated":"1566483696","dateModified":"1566483696"},{"type":"update","diffId":"16294","author":"taapas1128","id":"99144","dateCreated":"1566483618","dateModified":"1566483618"},{"type":"inline","comment":"When you add more tests, please include some with 1 dirty subrepo, and then another where the first subrepo is already merged\/resolved, and the second subrepo is dirty and pending a merge\/resolve.  If it simplifies the initial implementation to detect a dirty subrepo and then abort the `--abort` before it starts, that seems fine.","replyTo":"98944","isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"mharbison72","id":"98964","dateCreated":"1566232323","dateModified":"1566232323"},{"type":"inline","comment":"this line is not required.","replyTo":null,"isNewFile":"1","line":"992","lineLength":"0","path":"mercurial\/hg.py","diffId":"16262","author":"pulkit","id":"98962","dateCreated":"1566228426","dateModified":"1566228426"},{"type":"comment","comment":"Nice start! If I remember correctly, the mergestate stores the local version of the file. We can use that directly instead.","author":"pulkit","id":"98961","dateCreated":"1566228426","dateModified":"1566228426"},{"type":"update","diffId":"16262","author":"taapas1128","id":"98945","dateCreated":"1566135118","dateModified":"1566135118"},{"type":"inline","comment":"I have created a separate file will add more tests.","replyTo":"98873","isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"taapas1128","id":"98944","dateCreated":"1566133737","dateModified":"1566133737"},{"type":"update","diffId":"16261","author":"taapas1128","id":"98942","dateCreated":"1566133621","dateModified":"1566133621"},{"type":"inline","comment":"we need to hide this, maybe use more low level APIs. I haven't look at code in details, will try to look soon.","replyTo":null,"isNewFile":"1","line":"2129","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"pulkit","id":"98874","dateCreated":"1566070139","dateModified":"1566070139"},{"type":"inline","comment":"I suggest taking `update --abort` tests in a new file as we will need to extensively test that.","replyTo":null,"isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"pulkit","id":"98873","dateCreated":"1566070139","dateModified":"1566070139"},{"type":"update","diffId":"16251","author":"taapas1128","id":"98867","dateCreated":"1566069370","dateModified":"1566069370"},{"type":"update","diffId":"16250","author":"taapas1128","id":"98866","dateCreated":"1566058705","dateModified":"1566058705"},{"type":"update","diffId":"16249","author":"taapas1128","id":"98861","dateCreated":"1566058419","dateModified":"1566058419"}],"dateCreated":"1566058419","dateModified":"1592806928","status":"Needs Revision"},{"id":"7177","callsign":"HG","title":"rebase: introduce optional parent mapping","author":"joerg.sonnenberger","summary":"Consider the following DAG:\n\n  C   C'\n  |\\ \/|\n  A B D\n\nwith the goal of rebasing C to C' while switching the A parent to D.\nOut of the box, rebase will fail here as it doesn't know which parent of\nC to rewrite. With the new --parentmap option, this can be specified\nexplicitly. Use cases for this functionality are dealing with manual\nrebases without obsolescence markers, e.g. git-style forced commits.","testPlan":"","lineCount":"94","dependsOn":[],"reviewers":["martinvonz","baymax"],"ccs":["mercurial-patches","marmoute","mercurial-devel"],"actions":[{"type":"inline","comment":"`REV:REV` is valid revset so the result is quite confusing, if we go that route, we need anothr syntax.","replyTo":null,"isNewFile":"1","line":"884","lineLength":"0","path":"hgext\/rebase.py","diffId":"17411","author":"marmoute","id":"128831","dateCreated":"1591780504","dateModified":"1591780504"},{"type":"comment","comment":">>! In D7177#128760, @martinvonz wrote:\n>>>! In D7177#128757, @marmoute wrote:\n>>>>! In D7177#128756, @martinvonz wrote:\n>>>>>! In D7177#128740, @marmoute wrote:\n>>>>>>! In D7177#128389, @martinvonz wrote:\n>>>>> Maybe another option is to allow multiple `-d` arguments for this case? Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).\n>>>> \n>>>> That's interresting. How would that works with a practical case ?\n>>> \n>>> The example I have was meant to be a practical example for how to do it in the case given in the patch description :) But let me know if you meant some other aspect of \"how it works\". As I said, I'm not sure ant the BC bit of it at least.\n>> \n>> I meant how that would work in general, esepcially case more complicated than the basic base shown by @joerg.sonnenberger.\n> \n> I think the parents chosen by `-d` should only apply to the roots of the rebase set. If your rebase set has multiple roots and only some of them are merge commits, then we should probably error out.\n\nSo you suggestion would be to allow to specify two -d that would definive the two new parents of the root ? I suspect it would be a bit too narrow compared to the varienty of case we might have to handle. Maybe this is a mission for PlanPlan.\n\n> Anyway, I'm not sure it's realistic to make it work that way now, especially because of how inconsistent it would be with other arguments that accept revsets and only care about the highest revnum in the set (I think that was a mistake to do, but I understand why it was done that way and it's obviously too late to change it).\n\nI think the multiple -d value approach would works fine. (but for the other issue).\n\n>> Not that in @joerg base, B being ancestors of both C and C', we could probably behave better by default directly. Could we not ?\n> \n> As @joerg said in the patch description, there's no reasonable way to choose which of A and B to preserve (the current version of rebase wouldn't preserve either and would instead rebase all of A, B, and C).\n\nThe description got me confused, (I though C was rebased on C' (finding the naming strange)) while this is about C being rebased on D.\n\n","author":"marmoute","id":"128830","dateCreated":"1591780504","dateModified":"1591780504"},{"type":"comment","comment":">>! In D7177#128757, @marmoute wrote:\n>>>! In D7177#128756, @martinvonz wrote:\n>>>>! In D7177#128740, @marmoute wrote:\n>>>>>! In D7177#128389, @martinvonz wrote:\n>>>> Maybe another option is to allow multiple `-d` arguments for this case? Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).\n>>> \n>>> That's interresting. How would that works with a practical case ?\n>> \n>> The example I have was meant to be a practical example for how to do it in the case given in the patch description :) But let me know if you meant some other aspect of \"how it works\". As I said, I'm not sure ant the BC bit of it at least.\n> \n> I meant how that would work in general, esepcially case more complicated than the basic base shown by @joerg.sonnenberger.\n\nI think the parents chosen by `-d` should only apply to the roots of the rebase set. If your rebase set has multiple roots and only some of them are merge commits, then we should probably error out.\n\nAnyway, I'm not sure it's realistic to make it work that way now, especially because of how inconsistent it would be with other arguments that accept revsets and only care about the highest revnum in the set (I think that was a mistake to do, but I understand why it was done that way and it's obviously too late to change it).\n\n> \n> Not that in @joerg base, B being ancestors of both C and C', we could probably behave better by default directly. Could we not ?\n\nAs @joerg said in the patch description, there's no reasonable way to choose which of A and B to preserve (the current version of rebase wouldn't preserve either and would instead rebase all of A, B, and C).","author":"martinvonz","id":"128760","dateCreated":"1591719313","dateModified":"1591719313"},{"type":"comment","comment":">>! In D7177#128756, @martinvonz wrote:\n>>>! In D7177#128740, @marmoute wrote:\n>>>>! In D7177#128389, @martinvonz wrote:\n>>> Maybe another option is to allow multiple `-d` arguments for this case? Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).\n>> \n>> That's interresting. How would that works with a practical case ?\n> \n> The example I have was meant to be a practical example for how to do it in the case given in the patch description :) But let me know if you meant some other aspect of \"how it works\". As I said, I'm not sure ant the BC bit of it at least.\n\nI meant how that would work in general, esepcially case more complicated than the basic base shown by @joerg.sonnenberger.\n\nNot that in @joerg base, B being ancestors of both C and C', we could probably behave better by default directly. Could we not ?","author":"marmoute","id":"128757","dateCreated":"1591717623","dateModified":"1591717623"},{"type":"comment","comment":">>! In D7177#128740, @marmoute wrote:\n>>>! In D7177#128389, @martinvonz wrote:\n>> Maybe another option is to allow multiple `-d` arguments for this case? Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).\n> \n> That's interresting. How would that works with a practical case ?\n\nThe example I have was meant to be a practical example for how to do it in the case given in the patch description :) But let me know if you meant some other aspect of \"how it works\". As I said, I'm not sure ant the BC bit of it at least.","author":"martinvonz","id":"128756","dateCreated":"1591712758","dateModified":"1591712758"},{"type":"comment","comment":">>! In D7177#128389, @martinvonz wrote:\n> Maybe another option is to allow multiple `-d` arguments for this case? Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).\n\nThat's interresting. How would that works with a practical case ?","author":"marmoute","id":"128740","dateCreated":"1591703040","dateModified":"1591703040"},{"type":"comment","comment":"Maybe another option is to allow multiple `-d` arguments for this case? Something like `hg rebase -r C -d B -d D`. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support `hg rebase -r C -d 'B + D'` for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).","author":"martinvonz","id":"128389","dateCreated":"1590862104","dateModified":"1590862104"},{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126385","dateCreated":"1587570775","dateModified":"1587570775"},{"type":"reject","author":"baymax","id":"126384","dateCreated":"1587570775","dateModified":"1587570775"},{"type":"comment","comment":"I like the idea of using adding this to graft.","author":"marmoute","id":"117272","dateCreated":"1579797555","dateModified":"1579797555"},{"type":"comment","comment":"I personally haven't queued this yet because I don't really like the UI. Some things I recently worked on made me realize that `hg graft` doesn't currently preserve merges, but we could probably easily add a `--preserve-merges` option to it, so `hg co D; hg graft --base B --preserve-merges` would take care of the case in the commit message.","author":"martinvonz","id":"116330","dateCreated":"1579212527","dateModified":"1579212527"},{"type":"comment","comment":"I changed the commit message to indent the graph by two spaces. That way it renders better here in Phabricator.","author":"martinvonz","id":"105323","dateCreated":"1572413915","dateModified":"1572413915"},{"type":"update","diffId":"17411","author":"joerg.sonnenberger","id":"105313","dateCreated":"1572292928","dateModified":"1572292928"},{"type":"update","diffId":"17410","author":"joerg.sonnenberger","id":"105307","dateCreated":"1572279428","dateModified":"1572279428"}],"dateCreated":"1572279427","dateModified":"1591780504","status":"Needs Revision"},{"id":"8064","callsign":"HG","title":"split: add a --single flag to only ask for one split","author":"rdamazio","summary":"The majority of split invocations only want to split a revision in two,\nso this allows them to do that without getting a second chunk selector.\nI thought of making a generic \"max_splits\" flag, but that seemed like\noverkill.","testPlan":"","lineCount":"72","dependsOn":["7630"],"reviewers":["baymax"],"ccs":["mercurial-patches","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"128590","dateCreated":"1591637695","dateModified":"1591637695"},{"type":"reject","author":"baymax","id":"128589","dateCreated":"1591637695","dateModified":"1591637695"},{"type":"update","diffId":"19813","author":"rdamazio","id":"118999","dateCreated":"1580542108","dateModified":"1580542108"}],"dateCreated":"1580542108","dateModified":"1591637696","status":"Needs Revision"},{"id":"7630","callsign":"HG","title":"absorb: make the absorbed changeset be automatically \"evolved\"","author":"rdamazio","summary":"When a committed changeset is absorbed, this will make it so it's not used for\ncomputing the absorption, but is still recreated at the destination.","testPlan":"","lineCount":"92","dependsOn":["7631"],"reviewers":["baymax"],"ccs":["mercurial-patches","marmoute","pulkit","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"128586","dateCreated":"1591637695","dateModified":"1591637695"},{"type":"reject","author":"baymax","id":"128585","dateCreated":"1591637695","dateModified":"1591637695"},{"type":"comment","comment":"It looks like this series is introducing UI change of the same kind  as the one @martinvonz is looking into for `hg copy`. I'll try to have a look at both of them tomorrow.","author":"marmoute","id":"120511","dateCreated":"1581460836","dateModified":"1581460836"},{"type":"comment","comment":">>! In D7630#118997, @rdamazio wrote:\n>>>>! In D7630#117270, @marmoute wrote:\n>>>>>! In D7630#115320, @pulkit wrote:\n>>>>>> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n>>>>> \n>>>>> I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?\n>>>> \n>>>> Yep, that sounds good.\n>> \n>> I'm fine with doing this, but is there an efficient way to detect that it became empty?\n> \n> And by \"this\" I meant I'm fine with making it disappear if allowemptycommit is False. I don't fully understand how markers help accomplish that.\n\nWhen you try to create an empty commit, you'll get a `None` back for the nodeid (from `repo.commitctx()`, IIRC), so check for that.","author":"martinvonz","id":"120510","dateCreated":"1581445623","dateModified":"1581445623"},{"type":"update","diffId":"19982","author":"rdamazio","id":"119745","dateCreated":"1581045062","dateModified":"1581045062"},{"type":"update","diffId":"19980","author":"rdamazio","id":"119741","dateCreated":"1581044151","dateModified":"1581044151"},{"type":"comment","comment":">>>! In D7630#117270, @marmoute wrote:\n>>>>! In D7630#115320, @pulkit wrote:\n>>>>> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n>>>> \n>>>> I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?\n>>> \n>>> Yep, that sounds good.\n> \n> I'm fine with doing this, but is there an efficient way to detect that it became empty?\n\nAnd by \"this\" I meant I'm fine with making it disappear if allowemptycommit is False. I don't fully understand how markers help accomplish that.\n","author":"rdamazio","id":"118997","dateCreated":"1580541152","dateModified":"1580541152"},{"type":"comment","comment":">>! In D7630#115300, @pulkit wrote:\n> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n\nIt's not *always* empty - if there had been lines that it failed absorb (because it couldn't find where to absorb into), those would be left in the commit.\n\n>>! In D7630#117270, @marmoute wrote:\n>>>! In D7630#115320, @pulkit wrote:\n>>>> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n>>> \n>>> I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?\n>> \n>> Yep, that sounds good.\n\nI'm fine with doing this, but is there an efficient way to detect that it became empty?\n\n> This means generate split+fold markers. That is going to be fun to deal with :-). I dont' really have any much better idea however (the alternative seems to use simple prune markers, which is meh).\n\nI'm not following this part - why do you need markers at all?\n(you can argue whether you want them - but I don't see why you *need* them)\n","author":"rdamazio","id":"118992","dateCreated":"1580541029","dateModified":"1580541029"},{"type":"update","diffId":"19812","author":"rdamazio","id":"118991","dateCreated":"1580541026","dateModified":"1580541026"},{"type":"comment","comment":">>! In D7630#115320, @pulkit wrote:\n>>> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n>> \n>> I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?\n> \n> Yep, that sounds good.\n\nThis means generate split+fold markers. That is going to be fun to deal with :-). I dont' really have any much better idea however (the alternative seems to use simple prune markers, which is meh).","author":"marmoute","id":"117270","dateCreated":"1579797461","dateModified":"1579797461"},{"type":"comment","comment":">> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n> \n> I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?\n\nYep, that sounds good.\n","author":"pulkit","id":"115320","dateCreated":"1578937060","dateModified":"1578937078"},{"type":"comment","comment":">>! In D7630#112603, @rdamazio wrote:\n> Sorry for the upload mess (though it's arguably a `phabsend` bug :) ). Tried uploading the \"right\" way now.\n\nI reported that as https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6241.\n\n>>! In D7630#115300, @pulkit wrote:\n> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n\nI made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?","author":"martinvonz","id":"115319","dateCreated":"1578936945","dateModified":"1578936945"},{"type":"comment","comment":"This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. ","author":"pulkit","id":"115300","dateCreated":"1578931057","dateModified":"1578931057"},{"type":"update","diffId":"19049","author":"rdamazio","id":"114543","dateCreated":"1578357967","dateModified":"1578357967"},{"type":"update","diffId":"18874","author":"rdamazio","id":"113354","dateCreated":"1576741000","dateModified":"1576741000"},{"type":"update","diffId":"18844","author":"rdamazio","id":"113173","dateCreated":"1576644413","dateModified":"1576644413"},{"type":"update","diffId":"18842","author":"rdamazio","id":"113169","dateCreated":"1576644149","dateModified":"1576644149"},{"type":"update","diffId":"18729","author":"rdamazio","id":"112606","dateCreated":"1576304727","dateModified":"1576304727"},{"type":"comment","comment":"Sorry for the upload mess (though it's arguably a `phabsend` bug :) ). Tried uploading the \"right\" way now.","author":"rdamazio","id":"112603","dateCreated":"1576303334","dateModified":"1576303334"},{"type":"update","diffId":"18727","author":"rdamazio","id":"112600","dateCreated":"1576303329","dateModified":"1576303329"},{"type":"comment","comment":">>! In D7630#112243, @rdamazio wrote:\n> (on mobile) I think it was `hg phabsend -r .+.^`\n\nOhh, that makes some sense that phabsend might do it backwards if you pass the revisions backwards, but that's still clearly a bug. I'll report it in bugzilla if it's not already there. I'll manually update the parent\/child relationship on these reviews for now.\n","author":"martinvonz","id":"112244","dateCreated":"1576220268","dateModified":"1576220268"},{"type":"comment","comment":"(on mobile) I think it was `hg phabsend -r .+.^`\n\n  - {F454947, layout=link}","author":"rdamazio","id":"112243","dateCreated":"1576219938","dateModified":"1576219938"},{"type":"inline","comment":"Oh, it's added in D7631, which is marked as a *child* of this review. How did that happen? `hg phabsend` should set the relationships automatically. How did you run that command? Just `hg phabsend .^::.` or  similar? Or did you manually mark D7631 as a child?","replyTo":"112239","isNewFile":"1","line":"67","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"18665","author":"martinvonz","id":"112241","dateCreated":"1576219632","dateModified":"1576219632"},{"type":"inline","comment":"`hg absorb` has a `-r` flag? Did you forgot to upload some ancestors of this commit?","replyTo":null,"isNewFile":"1","line":"67","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"18665","author":"martinvonz","id":"112239","dateCreated":"1576217462","dateModified":"1576217462"},{"type":"update","diffId":"18665","author":"rdamazio","id":"112225","dateCreated":"1576216538","dateModified":"1576216538"}],"dateCreated":"1576216538","dateModified":"1591637695","status":"Needs Revision"},{"id":"7384","callsign":"HG","title":"commands: necessary annotations and suppresssions to pass pytype","author":"durin42","summary":"As with other places, there are some places where our types are just\ntoo complicated for pytype, so we put some suppressions in place.","testPlan":"","lineCount":"24","dependsOn":["7296"],"reviewers":["dlax","marmoute","baymax"],"ccs":["mercurial-patches","marmoute","dlax","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"128582","dateCreated":"1591637694","dateModified":"1591637694"},{"type":"reject","author":"baymax","id":"128581","dateCreated":"1591637694","dateModified":"1591637694"},{"type":"comment","comment":"There don't seems to be any remaininf feedback on this.","author":"marmoute","id":"120850","dateCreated":"1581668481","dateModified":"1581668481"},{"type":"accept","author":"marmoute","id":"120849","dateCreated":"1581668481","dateModified":"1581668481"},{"type":"inline","comment":"I think this comment should be removed since the `# pytype: disable` got removed in the last version of the diff.","replyTo":null,"isNewFile":"1","line":"4741","lineLength":"0","path":"mercurial\/commands.py","diffId":"18171","author":"dlax","id":"118745","dateCreated":"1580412376","dateModified":"1580412376"},{"type":"comment","comment":">>! In D7384#118739, @marmoute wrote:\n> What's up on this ? It seemed on a good track, but I don't think it landed. @dlax I think you offer to use a context manager got a warm welcome, I would says, go ahead with it.\n\nThe context manager got in through D7430.","author":"dlax","id":"118744","dateCreated":"1580412376","dateModified":"1580412376"},{"type":"comment","comment":"What's up on this ? It seemed on a good track, but I don't think it landed. @dlax I think you offer to use a context manager got a warm welcome, I would says, go ahead with it.","author":"marmoute","id":"118739","dateCreated":"1580409172","dateModified":"1580409172"},{"type":"update","diffId":"18171","author":"durin42","id":"109261","dateCreated":"1573854923","dateModified":"1573854923"},{"type":"inline","comment":"`revs` is always a `smartset.baseset` per af9c73f26371 so there should be no attribute error. Or is it because `logcmdutil.getlinerangerevs()` has no type annotation (whereas `logcmdutil.getrevs()` has some)?","replyTo":null,"isNewFile":"1","line":"4742","lineLength":"0","path":"mercurial\/commands.py","diffId":"18162","author":"dlax","id":"109205","dateCreated":"1573839647","dateModified":"1573839647"},{"type":"update","diffId":"18162","author":"durin42","id":"109201","dateCreated":"1573839083","dateModified":"1573839083"},{"type":"comment","comment":"I still want to keep the annotations I added. :)","author":"durin42","id":"109194","dateCreated":"1573838661","dateModified":"1573838661"},{"type":"comment","comment":"D7430 makes this changes unnecessary I think.","author":"dlax","id":"109165","dateCreated":"1573816122","dateModified":"1573816122"},{"type":"reject","author":"dlax","id":"109163","dateCreated":"1573816122","dateModified":"1573816122"},{"type":"inline","comment":"By all means!","replyTo":"108589","isNewFile":"1","line":"1127","lineLength":"0","path":"mercurial\/commands.py","diffId":"18071","author":"durin42","id":"108819","dateCreated":"1573766153","dateModified":"1573766153"},{"type":"update","diffId":"18099","author":"durin42","id":"108777","dateCreated":"1573765800","dateModified":"1573765800"},{"type":"inline","comment":"This one is sad. I think this can be sorted out by replacing the `try:\/finally:` with a context manager. (Can send a patch, if it sounds good to you.)","replyTo":null,"isNewFile":"1","line":"1127","lineLength":"0","path":"mercurial\/commands.py","diffId":"18071","author":"dlax","id":"108589","dateCreated":"1573724725","dateModified":"1573724725"},{"type":"update","diffId":"18071","author":"durin42","id":"108529","dateCreated":"1573703495","dateModified":"1573703495"}],"dateCreated":"1573703495","dateModified":"1591637694","status":"Needs Revision"},{"id":"8579","callsign":"HG","title":"context: avoid computing status twice when comparing among revisions","author":"rom1dep","summary":"","testPlan":"","lineCount":"13","dependsOn":[],"reviewers":["marmoute","durin42"],"ccs":["durin42","marmoute","mercurial-patches"],"actions":[{"type":"comment","comment":"Breaks many tests for status code, sadly.\n\n(Regrettably, I've already lost that output, and I need to go get lunch with family.)","author":"durin42","id":"128128","dateCreated":"1590511068","dateModified":"1590511068"},{"type":"reject","author":"durin42","id":"128127","dateCreated":"1590511068","dateModified":"1590511068"},{"type":"comment","comment":"This looks fine.","author":"marmoute","id":"128062","dateCreated":"1590500737","dateModified":"1590500737"},{"type":"accept","author":"marmoute","id":"128061","dateCreated":"1590500737","dateModified":"1590500737"},{"type":"comment","comment":"No real justification for, only found it weird, and since we have to do that test anyway I didn't think it would make perfs worse,\nDidn't run tests on it, though.","author":"rom1dep","id":"128003","dateCreated":"1590389462","dateModified":"1590389462"},{"type":"update","diffId":"21466","author":"rom1dep","id":"127999","dateCreated":"1590389282","dateModified":"1590389282"}],"dateCreated":"1590389282","dateModified":"1590511069","status":"Needs Revision"},{"id":"8571","callsign":"HG","title":"test: make test-doctest.py not assume it's run from a mercurial repo","author":"jcristau","summary":"This assumption fails when building and running tests from a source\ntarball, e.g.","testPlan":"","lineCount":"16","dependsOn":[],"reviewers":[],"ccs":["mercurial-patches"],"actions":[{"type":"comment","comment":"Need to fix some stuff, I'll get back to this tomorrow.","author":"jcristau","id":"127919","dateCreated":"1589920648","dateModified":"1589920648"},{"type":"plan-changes","author":"jcristau","id":"127918","dateCreated":"1589920648","dateModified":"1589920648"},{"type":"update","diffId":"21450","author":"jcristau","id":"127903","dateCreated":"1589916511","dateModified":"1589916511"}],"dateCreated":"1589916511","dateModified":"1589920648","status":"Changes Planned"},{"id":"6026","callsign":"HG","title":"lock: Improve the waiting for lock message which will help newcomers\n(issue6081)","author":"akshjain.jain74","summary":"","testPlan":"","lineCount":"71","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-patches","marmoute","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126762","dateCreated":"1588061930","dateModified":"1588061930"},{"type":"reject","author":"baymax","id":"126761","dateCreated":"1588061930","dateModified":"1588061930"},{"type":"comment","comment":"Gentle ping on this. This has been around for a long time, what's the status of it?","author":"marmoute","id":"117290","dateCreated":"1579799546","dateModified":"1579799546"},{"type":"comment","comment":">>! In D6026#88552, @pulkit wrote:\n> I am not sure the new message is much helpful. As JordiGH and others pointed out on IRC, it will definitely be helpful if we can show which operation has the lock right now.\n> \n> Something like:\n> \n> `waiting for lock on working directory of b held by process '*' running <cmd-name> on host '*'`\n\nSo for which commands we can show this message, like i got message when i run hg commit --amend sometimes ","author":"akshjain.jain74","id":"88558","dateCreated":"1551900706","dateModified":"1551900706"},{"type":"inline","comment":"I accept these changes while running test,  if i am not changing this then it will cause test failing","replyTo":"88554","isNewFile":"0","line":"18","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14277","author":"akshjain.jain74","id":"88557","dateCreated":"1551893473","dateModified":"1551893473"},{"type":"comment","comment":"okay @pulkit let me work upon your suggestion and ","author":"akshjain.jain74","id":"88556","dateCreated":"1551893473","dateModified":"1551893473"},{"type":"inline","comment":"The output is not correctly aligned. ","replyTo":null,"isNewFile":"1","line":"62","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14291","author":"pulkit","id":"88555","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"inline","comment":"still here are unrealted changes.","replyTo":"88052","isNewFile":"0","line":"18","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14277","author":"pulkit","id":"88554","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"inline","comment":"unrelated changes.","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"tests\/test-extdiff.t","diffId":"14291","author":"pulkit","id":"88553","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"comment","comment":"I am not sure the new message is much helpful. As JordiGH and others pointed out on IRC, it will definitely be helpful if we can show which operation has the lock right now.\n\nSomething like:\n\n`waiting for lock on working directory of b held by process '*' running <cmd-name> on host '*'`","author":"pulkit","id":"88552","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"update","diffId":"14291","author":"akshjain.jain74","id":"88119","dateCreated":"1551530162","dateModified":"1551530162"},{"type":"comment","comment":"@pulkit done changes as per your suggestion in lock file too but what did you meant by storelock?","author":"akshjain.jain74","id":"88059","dateCreated":"1551392049","dateModified":"1551392049"},{"type":"update","diffId":"14279","author":"akshjain.jain74","id":"88056","dateCreated":"1551391885","dateModified":"1551391885"},{"type":"inline","comment":"unrelated changes in the test file here and below.","replyTo":null,"isNewFile":"0","line":"18","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14277","author":"pulkit","id":"88052","dateCreated":"1551389487","dateModified":"1551389487"},{"type":"inline","comment":"remove which file manually to continue?\n\nI think we should delete the `If it still fails, ..... remove the file manually to continue` part.","replyTo":null,"isNewFile":"1","line":"316","lineLength":"0","path":"hgext\/journal.py","diffId":"14277","author":"pulkit","id":"88051","dateCreated":"1551389487","dateModified":"1551389487"},{"type":"inline","comment":"This is only for locking namejournal.lock and not for working directory lock and store lock. We need to improve message there too.","replyTo":null,"isNewFile":"1","line":"310","lineLength":"0","path":"hgext\/journal.py","diffId":"14277","author":"pulkit","id":"88050","dateCreated":"1551389487","dateModified":"1551389487"},{"type":"update","diffId":"14277","author":"akshjain.jain74","id":"88048","dateCreated":"1551388596","dateModified":"1551388596"},{"type":"update","diffId":"14274","author":"akshjain.jain74","id":"88039","dateCreated":"1551376882","dateModified":"1551376882"},{"type":"update","diffId":"14273","author":"akshjain.jain74","id":"88038","dateCreated":"1551373745","dateModified":"1551373745"},{"type":"update","diffId":"14272","author":"akshjain.jain74","id":"88037","dateCreated":"1551373367","dateModified":"1551373367"},{"type":"update","diffId":"14271","author":"akshjain.jain74","id":"88036","dateCreated":"1551373151","dateModified":"1551373151"},{"type":"comment","comment":"Ya I am sending that  just trying to find out the file","author":"akshjain.jain74","id":"87909","dateCreated":"1551191027","dateModified":"1551191027"},{"type":"comment","comment":"This patch does not changes any code. It only changes some test output. You need to change the error message in the code.","author":"pulkit","id":"87908","dateCreated":"1551190913","dateModified":"1551190913"},{"type":"update","diffId":"14244","author":"akshjain.jain74","id":"87894","dateCreated":"1551173448","dateModified":"1551173448"}],"dateCreated":"1551173448","dateModified":"1588061931","status":"Needs Revision"},{"id":"6123","callsign":"HG","title":"similar: add condition to avoid Zerodivisonerror in function _score() (issue6099)","author":"akshjain.jain74","summary":"","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":["durin42","baymax"],"ccs":["mercurial-patches","marmoute","av6","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126758","dateCreated":"1588061929","dateModified":"1588061929"},{"type":"reject","author":"baymax","id":"126757","dateCreated":"1588061929","dateModified":"1588061929"},{"type":"comment","comment":"Gentle ping on this. This has been around for a long time, what's the status of it?","author":"marmoute","id":"117292","dateCreated":"1579799599","dateModified":"1579799599"},{"type":"inline","comment":"yes actually \ud83d\ude05  i did'nt noticed that ","replyTo":"89412","isNewFile":"1","line":"68","lineLength":"0","path":"mercurial\/similar.py","diffId":"14487","author":"akshjain.jain74","id":"89432","dateCreated":"1552659675","dateModified":"1552659675"},{"type":"update","diffId":"14508","author":"akshjain.jain74","id":"89430","dateCreated":"1552659596","dateModified":"1552659596"},{"type":"comment","comment":"thanks for the review\n","author":"akshjain.jain74","id":"89422","dateCreated":"1552658279","dateModified":"1552658279"},{"type":"comment","comment":">>! In D6123#89410, @pulkit wrote:\n> Can you try to add a test for this?\n\nyes i can definitely try to add test for this ","author":"akshjain.jain74","id":"89421","dateCreated":"1552658267","dateModified":"1552658267"},{"type":"inline","comment":"no need for this else. you can `return 0` without else.","replyTo":null,"isNewFile":"1","line":"68","lineLength":"0","path":"mercurial\/similar.py","diffId":"14487","author":"pulkit","id":"89412","dateCreated":"1552657477","dateModified":"1552657477"},{"type":"inline","comment":"we can do `if lengths:` here.","replyTo":null,"isNewFile":"1","line":"66","lineLength":"0","path":"mercurial\/similar.py","diffId":"14487","author":"pulkit","id":"89411","dateCreated":"1552657477","dateModified":"1552657477"},{"type":"comment","comment":"Can you try to add a test for this?","author":"pulkit","id":"89410","dateCreated":"1552657477","dateModified":"1552657477"},{"type":"update","diffId":"14487","author":"akshjain.jain74","id":"89272","dateCreated":"1552508232","dateModified":"1552508232"},{"type":"comment","comment":"actually  i am not getting what can be the proper topic for this :(","author":"akshjain.jain74","id":"89249","dateCreated":"1552501010","dateModified":"1552501010"},{"type":"comment","comment":"sorry for that , but can you tell me in what condition this function will return none value?","author":"akshjain.jain74","id":"89248","dateCreated":"1552500860","dateModified":"1552500860"},{"type":"inline","comment":"`None > 1` is still an issue, see my comment above.","replyTo":null,"isNewFile":"1","line":"66","lineLength":"1","path":"mercurial\/similar.py","diffId":"14482","author":"av6","id":"89240","dateCreated":"1552500162","dateModified":"1552500162"},{"type":"comment","comment":"Okay, let's go over #1 in https:\/\/www.mercurial-scm.org\/wiki\/ContributingChanges#Submission_checklist once more. If you want to know what a good \"topic\" is, look at what other people do. How patches that get accepted generally look. How bug-fixing commits are worded.\n\nSecondly, about that capitalization. I'm sorry if this is some sort of silly autocorrect that's doing it for you, I really hope you're not writing commit messages on a phone.","author":"av6","id":"89239","dateCreated":"1552500162","dateModified":"1552500162"},{"type":"update","diffId":"14482","author":"akshjain.jain74","id":"89237","dateCreated":"1552498479","dateModified":"1552498479"},{"type":"comment","comment":"Sorry for the various mistake\n I will correct everything in an hour thanks","author":"akshjain.jain74","id":"89222","dateCreated":"1552470438","dateModified":"1552470438"},{"type":"inline","comment":"This returns None in some cases, and code that uses `_score()` and `score()` tries to compare it to an integer. In Python3 `None > 1` raises TypeError.","replyTo":null,"isNewFile":"1","line":"67","lineLength":"0","path":"mercurial\/similar.py","diffId":"14477","author":"av6","id":"89221","dateCreated":"1552469028","dateModified":"1552469028"},{"type":"inline","comment":"This is some... interesting syntax. Is this valid Python?","replyTo":null,"isNewFile":"1","line":"66","lineLength":"1","path":"mercurial\/similar.py","diffId":"14477","author":"av6","id":"89220","dateCreated":"1552468824","dateModified":"1552468824"},{"type":"comment","comment":"I find it troubling that we now have contributors that don't follow #1 in https:\/\/www.mercurial-scm.org\/wiki\/ContributingChanges#Submission_checklist. Potentially #4 too (as Pulkit commented).\n\nSeriously, the title is terrible at describing what this patch fixes and where. The commit message could briefly mention why\/when this condition is even required.","author":"av6","id":"89219","dateCreated":"1552468824","dateModified":"1552468824"},{"type":"comment","comment":"Oh sorry ,my bad  I think that is by mistake I will correct it now\nIthink while committing I added that file by mistake","author":"akshjain.jain74","id":"89217","dateCreated":"1552468624","dateModified":"1552468624"},{"type":"inline","comment":"Is this change required for this patch?","replyTo":null,"isNewFile":"1","line":"1127","lineLength":"0","path":"hgext\/histedit.py","diffId":"14477","author":"pulkit","id":"89214","dateCreated":"1552467285","dateModified":"1552467285"},{"type":"update","diffId":"14477","author":"akshjain.jain74","id":"89176","dateCreated":"1552414170","dateModified":"1552414170"}],"dateCreated":"1552414170","dateModified":"1588061930","status":"Needs Revision"},{"id":"6027","callsign":"HG","title":"mq: make unshelve to apply on modified mq patch (issue4318)","author":"navaneeth.suresh","summary":"unshelve wasn't working on a modified mq patch. I added checks for\nnot aborting on a modified mq patch in both rebase and mq.\n\nChecking `repo.vfs.exists('unshelverebasestate')` works in rebase,\nnot in mq. I used `cmdutil.unfinishedstates` to find `shelvedstate`\nin mq.","testPlan":"","lineCount":"29","dependsOn":[],"reviewers":["martinvonz","baymax"],"ccs":["mercurial-patches","marmoute","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126754","dateCreated":"1588061928","dateModified":"1588061928"},{"type":"reject","author":"baymax","id":"126753","dateCreated":"1588061928","dateModified":"1588061928"},{"type":"comment","comment":"Waht'a sup on this. Seems to be open for a long while.","author":"marmoute","id":"117296","dateCreated":"1579799857","dateModified":"1579799857"},{"type":"comment","comment":"> It doesn't make sense to check the existence of 'shelvedstate' in a static\n> table.\n> \n> Can't we somehow get around the mq in a similar way to shelve.getcommitfunc()?\n> I don't think it's good idea to rely on state files saved on disk.\n\nI felt that the only workaround to stop aborting unshelve on a modified mq patch should be adding a check on `mq.abortifwdirpatched()`. Will try to investigate in `shelve.getcommitfunc()` for sure. Thanks.","author":"navaneeth.suresh","id":"89928","dateCreated":"1553624502","dateModified":"1553624502"},{"type":"comment","comment":"> --- a\/hgext\/mq.py\n> +++ b\/hgext\/mq.py\n> @@ -3518,7 +3518,10 @@\n>                  delattr(self.unfiltered(), r'mq')\n>  \n>          def abortifwdirpatched(self, errmsg, force=False):\n> -            if self.mq.applied and self.mq.checkapplied and not force:\n> +            shelveinprogress = any('shelvedstate' in state\n> +                                    for state in cmdutil.unfinishedstates)\n> +            if (self.mq.applied and self.mq.checkapplied and not force and\n> +                not shelveinprogress):\n\nIt doesn't make sense to check the existence of 'shelvedstate' in a static\ntable.\n\nCan't we somehow get around the mq in a similar way to shelve.getcommitfunc()?\nI don't think it's good idea to rely on state files saved on disk.","author":"yuja","id":"89919","dateCreated":"1553552983","dateModified":"1553552983"},{"type":"comment","comment":"Gentle ping for review.","author":"navaneeth.suresh","id":"89906","dateCreated":"1553450952","dateModified":"1553450952"},{"type":"update","diffId":"14400","author":"navaneeth.suresh","id":"88740","dateCreated":"1552069564","dateModified":"1552069564"},{"type":"comment","comment":"Ping for review.","author":"navaneeth.suresh","id":"88530","dateCreated":"1551851154","dateModified":"1551851154"},{"type":"update","diffId":"14245","author":"navaneeth.suresh","id":"87900","dateCreated":"1551183856","dateModified":"1551183856"}],"dateCreated":"1551183856","dateModified":"1588061929","status":"Needs Revision"},{"id":"7716","callsign":"HG","title":"rust-discovery: partial switch to typestate pattern","author":"gracinet","summary":"The `PartialDiscovery` object owns two data fields that are\nlazily evaluated: the set of undecided revisions, and the\nchildren cache. That laziness is known to be essential for\nperformance.\n\nIn the previous version, we were using `Option<T>`, which led\nus to methods such as `ensure_undecided()` followed by calls to\n`self.undecided.as_ref().unwrap()`, as it was the simplest way\nto avoid reference sharing problems, but that wasn't\nsatisfying. Human readers knew that panicking was indeed\nimpossible, but that wasn't enforced by the compiler.\n\nWe had something similar yet less pervasive with the early\nrelease of `target_heads`.\n\nThe reviewer, Kevin Cox, then suggested to use a code pattern\nknown as typestate: different types to represent the successive\nstages, with the second one always having an undecided set.\n\nThis is what we are doing here.  Now we have two state types:\n`OnlyCommon` and `WithUndecided`.\nOnly the first has the `target_heads` member; only the second\nhas the `undecided` member.\n\nIt makes the code a bit longer, because we have to make\n`PartialDiscovery` a wrapper enum for identical consumption\nwithin hg-cpython and reexpose the public interface.\nBut it makes the inner code more focused, clearer and\nbetter checked by the compiler. A few further simplifications\nwill be made in following changesets thanks to this.\n\nA key point that we didn't know how to solve\nin the first version was the in-place mutation of that wrapper\nenum, provided by the `mutate_undecided()` method.\n\nThis is partial because we don't address the children cache.\nWe'll do that in a follow-up also.\n\nAlso some methods and doc-comments have been kept on the inner\nstructs for readability of this changesets, but they will\nbe factorized on the wrapper enum in a next move","testPlan":"","lineCount":"381","dependsOn":[],"reviewers":["martinvonz"],"ccs":["mercurial-patches","marmoute","martinvonz","Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7716#126417, @marmoute wrote:\n> cc @Alphare is this still relevant ?\n\nIt is. @gracinet told me he would want to come back to this series when he has time. Since it's a cleanup series it's not urgent in any way, but we would all like to have this upstream some day.","author":"Alphare","id":"126506","dateCreated":"1587628319","dateModified":"1587628319"},{"type":"comment","comment":"cc @Alphare is this still relevant ?","author":"marmoute","id":"126417","dateCreated":"1587570881","dateModified":"1587570881"},{"type":"comment","comment":"I'm gonna give it a try, yes. About the namings, I'm thinking of `<Cheap>` and `<Expensive>`. It doesn't describe the contents, but it's really clear about the intent.","author":"gracinet","id":"114210","dateCreated":"1577622485","dateModified":"1577622485"},{"type":"comment","comment":">>! In D7716#114043, @gracinet wrote:\n> @martinvonz yes, I've thinked of it after I made this one, but somehow I thought this was enough for a first try.\n\nIt seems like it would be a lot of churn to take this patch and then a follow-up that rewrites it. I'd be much happier to take a patch that cleaner version right away (and it sounds like we both think it would be cleaner).\n\n> \n> Yes, we could have `PartialDiscovery<Start>`,  and `PartialDiscovery<Computed>`, with  `Start` being a pure marker,  and `Computed` actually holding the undecided set and the children cache (anticipating on a later changeset), that would be more elegant and it would better organize the boiler plate.\n> \n> Don't hesitate if you come up with better namings.\n\nI haven't even reviewed in enough detail to know what the states represent, so I don't have any suggestions yet :)","author":"martinvonz","id":"114044","dateCreated":"1577486308","dateModified":"1577486308"},{"type":"comment","comment":"@martinvonz yes, I've thinked of it after I made this one, but somehow I thought this was enough for a first try.\n\nYes, we could have `PartialDiscovery<Start>`,  and `PartialDiscovery<Computed>`, with  `Start` being a pure marker,  and `Computed` actually holding the undecided set and the children cache (anticipating on a later changeset), that would be more elegant and it would better organize the boiler plate.\n\nDon't hesitate if you come up with better namings.","author":"gracinet","id":"114043","dateCreated":"1577485532","dateModified":"1577485532"},{"type":"comment","comment":"Did you consider encoding the state in a type parameter to `PartialDiscovery`? I think that would make the call sites simpler. See the last variation on http:\/\/cliffle.com\/blog\/rust-typestate\/ for what I mean.","author":"martinvonz","id":"113817","dateCreated":"1577468534","dateModified":"1577468534"},{"type":"reject","author":"martinvonz","id":"113816","dateCreated":"1577468534","dateModified":"1577468534"},{"type":"comment","comment":"@durin42 this Diffrential and its descendants are what I've told you about in our latest chat: implementing suggestions by @kevincox for a much cleaner an robust code.\nI intend to provide the upcoming rust-nodemap series using the same kind of pattern. I believe @Alphare wants to clean up Dirstate related code in similar ways.","author":"gracinet","id":"113739","dateCreated":"1577196081","dateModified":"1577196081"},{"type":"update","diffId":"18924","author":"gracinet","id":"113682","dateCreated":"1577195389","dateModified":"1577195389"}],"dateCreated":"1577195389","dateModified":"1587628319","status":"Needs Revision"},{"id":"8281","callsign":"HG","title":"narrow: escape includepats\/excludepats when sending over the wire","author":"spectral","summary":"The escaping chosen was RFC 4180-like in that it wraps the values that are to be\nescaped in double quote (`\"`) characters, and doubles any embedded double quote\ncharacters. It differs from RFC 4180 in what is escaped; the escaping is only\napplied if the item contains a `,` character or starts with a `\"` character. RFC\n4180 states that `\"` characters embedded in a value that isn't escaped are not\nallowed, and it also states that \\r and \\n characters should trigger an item to\nbe escaped.\n\nThe differences from RFC 4180 are intentional:\n- the include and exclude patterns can't contain a `,` character today (that's\n  what's being fixed), so surrounding them in `\"` characters won't really change\n  anything.\n- the include and exclude patterns today can't start with a `\"` character, so by\n  *not* escaping all strings that have an embedded `\"` unless they start with a\n  `\"` character (for future compatibility), we maintain BC.\n- the include and exclude patterns aren't multi-line, so \\r and \\n are\n  irrelevant (and technically allowed in the patterns, though Mercurial is\n  generally unable to reason about filenames that contain newlines).\n\nAlternatives considered:\n\nFull RFC 4180 encoding and decoding:\n- this would have been a breaking change for any include\/exclude\n  pattern that includes a `\"` in the name if a new client talks to an old\n  server. This is quite unlikely to cause problems in practice, but was easy to\n  avoid.\n- this would have required the decoder to handle \\r and \\n characters specially,\n  which would complicate it significantly.\n- the `csv` module in Python would have provided this to us, but it requires\n  `str` on python3, and we only have bytes. It's not generically safe to convert\n  these patterns to `str`, though perhaps roundtripping the string through\n  fsencode and fsdecode would have been acceptable?\n\nOther escaping mechanisms:\n- the original version of this change did use a different (home-grown) escaping\n  mechanism. This received pushback during review.\n- using \\ escaping (`\\`->`\\\\`, and `,` -> `\\,`) is annoying to decode, though\n  overall pretty similar to what we have to do here. It would introduce\n  significantly more changes for cross-platform and cross-version compatibility,\n  however, as a server that encounters a string with `\\,` can't know if the\n  client is escaping a comma, or if the client is old and the path ends in a\n  backslash (among other ambiguities).\n- using the existing batch escaping would likely have worked, but would\n  introduce cross-version ambiguities if any path contained a `:` character\n  followed by one of the four characters used in that escaping mechanism. The\n  author does not know if their deployment has any paths with these character\n  sequences in them, so decided to err on the side of caution.","testPlan":"","lineCount":"274","dependsOn":[],"reviewers":["durin42","martinvonz","marmoute"],"ccs":["mercurial-patches","marmoute","mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"If I understood the situation correctly, a rewrite in planned.","author":"marmoute","id":"126457","dateCreated":"1587571865","dateModified":"1587571865"},{"type":"reject","author":"marmoute","id":"126456","dateCreated":"1587571865","dateModified":"1587571865"},{"type":"comment","comment":">>! In D8281#124246, @spectral wrote:\n>>>! In D8281#124129, @durin42 wrote:\n>>>>! In D8281#124058, @marmoute wrote:\n>>> 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.\n>> \n>> +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.\n> \n> 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.\n\nI know the feeling, thanks a lot for revisiting you original plan.\n\n> \n> So, before I go down another rabbit hole, here's what I'm thinking:\n> \n> - Server emits a new capability `narrow-exp-1-escaped` (in addition to the current `narrow-exp-1`, this is not replacing the existing capability)\n> - wireprototypes's map will change these items from csv to csv.escaped \n> - Compatible clients will detect this capability from the server and send items of type csv.escaped during getbundle with keys like `<previousname>.escaped` (ex: `include.escaped`). If the server doesn't support csv.escaped, the client sends with the old names (unescaped).\n> - The escaping will be urllibcompat.quote\n> - The server will strip the `.escaped` suffix on the keys, split on comma, and urllibcompat.unquote the individual items\n\nThis looks overall good to me.\n\n> - I'm *not* expecting to do anything about `\\` -> `\/` conversion.\n\nDoes this means the client side is expected to enforce using `\/` as the directory separator ?\n\n> Since these are part of `getbundle`, I haven't found a way of doing this that's not one of:\n> - a custom escaping mechanism that's backwards compatible\n> - adding a capability and renaming the keys that are sent (so the server can tell when it needs to unescape)\n> - having the client always send duplicate items (i.e. send `include` and `include.escaped`). I'm not even sure that older servers would tolerate receiving keys they aren't expecting.\n\nIt would not work. Server would reject unknown arguments to `getbundle`.\n\n> - having the client only escape when necessary (i.e. it includes a comma), and then always send the path as include.escaped (which runs into the problem of old servers rejecting).\n\nIn my opinion, I don't think we get much benefit of conditional escaping. So keeping things simple seems better.\n\n> - having the server always unescape and the client always escape. This breaks the server's ability to interact with older clients that aren't escaping (which we'll need to support for at least a week or two).\n\nAs much as I think we don't need strong BC on narrow because it is experimental, have a couple of version that can still speak to each other is preferable.\n\n> For the non-getbundle parts (I think the wireproto command is 'widen'), we can easily make a widen2 or something, but it's probably easier to just keep the same command name and do the same thing as in getbundle: detect the capability, send as foo.escaped if supported.\n\n","author":"marmoute","id":"124269","dateCreated":"1584764191","dateModified":"1584764191"},{"type":"comment","comment":">>! In D8281#124246, @spectral wrote:\n> - I'm *not* expecting to do anything about `\\` -> `\/` conversion. \n\nSo would there be some interoperability issue between Windows and not-Windows if paths aren't pconverted, if paths can also come from the server as Martin mentioned?  Is there anything here that makes it more difficult to pconvert in the future?  (I assume it only came up in the first place to allow the custom escaping.  I understand your frustration, so I'm not looking to sign you up for more work.  But I only know about narrow from a very high conceptual level, so I figure I might as well ask now and save this info for later.)","author":"mharbison72","id":"124249","dateCreated":"1584758666","dateModified":"1584758666"},{"type":"comment","comment":">>! In D8281#124247, @martinvonz wrote:\n>>>! In D8281#124246, @spectral wrote: \n>> - Server emits a new capability `narrow-exp-1-escaped` (in addition to the current `narrow-exp-1`, this is not replacing the existing capability)\n> \n> nit: I *think* the \"1\" in the name was supposed to be a version number, so the new capability's name would be `narrow-exp-2`.\n\nYes, I had assumed that as well. This isn't really a new version of the protocol, though, just a minor tweak, and it's primarily to the 'csv' type used in getbundle (see the current version of this patch that adds 'qcsv' for the actual locations it's used). Honestly I went back and forth between announcing it as `getbundle-csv-escaped` and something related to narrow (and ended up on narrow, as you see, since while it's generically useful besides narrow, nothing else needs it today, and future things wouldn't need this to be announced forever - they'll always have used foo.escaped and been transmitted as escaped).\n\n> Maybe no one uses the \"widen\" command so we don't even need to worry about compatibility there?\n\nI don't know how often it's used :) I just know that there's something *not* getbundle-related in narrowwirepeer.py (looks like it's called `narrow_widen` that needed to be modified or else the tests wouldn't pass. I honestly don't even know if we're using it internally at Google right now. If not, that's fewer things to change, which I'm OK with :)\n\n","author":"spectral","id":"124248","dateCreated":"1584757570","dateModified":"1584757570"},{"type":"comment","comment":">>! In D8281#124246, @spectral wrote:\n>>>! In D8281#124129, @durin42 wrote:\n>>>>! In D8281#124058, @marmoute wrote:\n>>> 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.\n>> \n>> +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.\n> \n> 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. \n> \n> So, before I go down another rabbit hole, here's what I'm thinking:\n> \n> - Server emits a new capability `narrow-exp-1-escaped` (in addition to the current `narrow-exp-1`, this is not replacing the existing capability)\n\nnit: I *think* the \"1\" in the name was supposed to be a version number, so the new capability's name would be `narrow-exp-2`.\n\n> - wireprototypes's map will change these items from csv to csv.escaped \n> - Compatible clients will detect this capability from the server and send items of type csv.escaped during getbundle with keys like `<previousname>.escaped` (ex: `include.escaped`). If the server doesn't support csv.escaped, the client sends with the old names (unescaped).\n> - The escaping will be urllibcompat.quote\n> - The server will strip the `.escaped` suffix on the keys, split on comma, and urllibcompat.unquote the individual items\n> - I'm *not* expecting to do anything about `\\` -> `\/` conversion. \n\nThis all sounds good to me.\n\n> \n> Since these are part of `getbundle`, I haven't found a way of doing this that's not one of:\n> - a custom escaping mechanism that's backwards compatible\n> - adding a capability and renaming the keys that are sent (so the server can tell when it needs to unescape)\n> - having the client always send duplicate items (i.e. send `include` and `include.escaped`). I'm not even sure that older servers would tolerate receiving keys they aren't expecting.\n> - having the client only escape when necessary (i.e. it includes a comma), and then always send the path as include.escaped (which runs into the problem of old servers rejecting).\n> - having the server always unescape and the client always escape. This breaks the server's ability to interact with older clients that aren't escaping (which we'll need to support for at least a week or two).\n> \n> For the non-getbundle parts (I think the wireproto command is 'widen'), we can easily make a widen2 or something, but it's probably easier to just keep the same command name and do the same thing as in getbundle: detect the capability, send as foo.escaped if supported.\n\nMaybe no one uses the \"widen\" command so we don't even need to worry about compatibility there?\n","author":"martinvonz","id":"124247","dateCreated":"1584747164","dateModified":"1584747164"},{"type":"comment","comment":">>! In D8281#124129, @durin42 wrote:\n>>>! In D8281#124058, @marmoute wrote:\n>> 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.\n> \n> +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.\n\nI'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. \n\nSo, before I go down another rabbit hole, here's what I'm thinking:\n\n- Server emits a new capability `narrow-exp-1-escaped` (in addition to the current `narrow-exp-1`, this is not replacing the existing capability)\n- wireprototypes's map will change these items from csv to csv.escaped \n- Compatible clients will detect this capability from the server and send items of type csv.escaped during getbundle with keys like `<previousname>.escaped` (ex: `include.escaped`). If the server doesn't support csv.escaped, the client sends with the old names (unescaped).\n- The escaping will be urllibcompat.quote\n- The server will strip the `.escaped` suffix on the keys, split on comma, and urllibcompat.unquote the individual items\n- I'm *not* expecting to do anything about `\\` -> `\/` conversion. \n\nSince these are part of `getbundle`, I haven't found a way of doing this that's not one of:\n- a custom escaping mechanism that's backwards compatible\n- adding a capability and renaming the keys that are sent (so the server can tell when it needs to unescape)\n- having the client always send duplicate items (i.e. send `include` and `include.escaped`). I'm not even sure that older servers would tolerate receiving keys they aren't expecting.\n- having the client only escape when necessary (i.e. it includes a comma), and then always send the path as include.escaped (which runs into the problem of old servers rejecting).\n- having the server always unescape and the client always escape. This breaks the server's ability to interact with older clients that aren't escaping (which we'll need to support for at least a week or two).\n\nFor the non-getbundle parts (I think the wireproto command is 'widen'), we can easily make a widen2 or something, but it's probably easier to just keep the same command name and do the same thing as in getbundle: detect the capability, send as foo.escaped if supported.\n\n","author":"spectral","id":"124246","dateCreated":"1584745742","dateModified":"1584745742"},{"type":"comment","comment":">>! In D8281#124058, @marmoute wrote:\n> 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.\n\n+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.","author":"durin42","id":"124129","dateCreated":"1584719870","dateModified":"1584719870"},{"type":"comment","comment":"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.\n\nI am really not enthousiatic with having our own version of an encoding. Because this means extra overhead for people working on this in the future. Especially if it needs to be reimplemented (eg: in rust). If we drop the hard BC constraint on this, like starting from scratch. What would be your (@spectral ) encoding of choice ? could we got for something simple but widely available like url-encode ?","author":"marmoute","id":"124058","dateCreated":"1584660947","dateModified":"1584660947"},{"type":"update","diffId":"20819","author":"spectral","id":"123958","dateCreated":"1584482355","dateModified":"1584482355"},{"type":"update","diffId":"20818","author":"spectral","id":"123957","dateCreated":"1584481806","dateModified":"1584481806"},{"type":"update","diffId":"20813","author":"spectral","id":"123932","dateCreated":"1584480325","dateModified":"1584480325"},{"type":"update","diffId":"20789","author":"spectral","id":"123805","dateCreated":"1584152998","dateModified":"1584152998"},{"type":"comment","comment":">>! In D8281#123659, @mharbison72 wrote:\n>>>! In D8281#123625, @spectral wrote:\n>>>>! In D8281#123621, @mharbison72 wrote:\n>>> The Windows path changes seem like a good idea.\n>>> \n>>> 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.)\n>> \n>> 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?)\n> \n> 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.\n\nThey are stored in .hg\/store\/narrowspec. They usually get into that file via `hg clone --narrow --include` and similar, but the server may also send them. We should ideally do the conversion early when the user provides them. I think the pconvert in this patch is to handle existing repos as well as possible.","author":"martinvonz","id":"123662","dateCreated":"1584112673","dateModified":"1584112673"},{"type":"comment","comment":">>! In D8281#123625, @spectral wrote:\n>>>! In D8281#123621, @mharbison72 wrote:\n>> The Windows path changes seem like a good idea.\n>> \n>> 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.)\n> \n> 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?)\n\nI 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.","author":"mharbison72","id":"123659","dateCreated":"1584107877","dateModified":"1584107877"},{"type":"inline","comment":"Let's name it `decode_csv_paths` now that `_` are permitted. It woul dbe easier to read.","replyTo":null,"isNewFile":"1","line":"220","lineLength":"0","path":"mercurial\/wireprototypes.py","diffId":"20767","author":"marmoute","id":"123652","dateCreated":"1584089916","dateModified":"1584089916"},{"type":"inline","comment":"Let's name it `encode_csv_paths` now that `_` are permitted. It woul dbe easier to read.","replyTo":null,"isNewFile":"1","line":"183","lineLength":"0","path":"mercurial\/wireprototypes.py","diffId":"20767","author":"marmoute","id":"123651","dateCreated":"1584089916","dateModified":"1584089916"},{"type":"comment","comment":"The escaping scheme is a bit puzzling to me. Coudl we use something more standard for this ? (like urlencode).\n\n(requesting change of the function name. Now that we can, lets make them readable)","author":"marmoute","id":"123650","dateCreated":"1584089916","dateModified":"1584089916"},{"type":"reject","author":"marmoute","id":"123649","dateCreated":"1584089916","dateModified":"1584089916"},{"type":"comment","comment":">>! In D8281#123625, @spectral wrote:\n>>>! In D8281#123621, @mharbison72 wrote:\n>> The Windows path changes seem like a good idea.\n>> \n>> 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.)\n> \n> 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?)\n\nIt's a little weird to me that there's no step corresponding to `pconvert()` in the decoding function. Maybe we should do the `pconvert()` step outside `encodecsvpaths()`, maybe in `narrowspec.normalizepattern()`? However, that would make it impossible to have backslashes in paths in the narrowspec on Windows even after this patch (because they would always be converted to slashes), including narrowspecs returned from the server. However^2, maybe it wouldn't work to check out such paths on Windows anyway, so it doesn't really matter (so it's fine to call `pconvert()`)?","author":"martinvonz","id":"123640","dateCreated":"1584078474","dateModified":"1584078474"},{"type":"comment","comment":">>! In D8281#123621, @mharbison72 wrote:\n> The Windows path changes seem like a good idea.\n> \n> 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.)\n\nLet 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?)","author":"spectral","id":"123625","dateCreated":"1584077397","dateModified":"1584077397"},{"type":"update","diffId":"20767","author":"spectral","id":"123624","dateCreated":"1584076873","dateModified":"1584076873"},{"type":"comment","comment":"The Windows path changes seem like a good idea.\n\nWould 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.)","author":"mharbison72","id":"123621","dateCreated":"1584076400","dateModified":"1584076400"},{"type":"update","diffId":"20765","author":"spectral","id":"123606","dateCreated":"1584072745","dateModified":"1584072745"}],"dateCreated":"1584072745","dateModified":"1587571865","status":"Needs Revision"},{"id":"3444","callsign":"HG","title":"tests: comprehensively test exit handling","author":"indygreg","summary":"Rust `hg` currently has some test failures around exit handling.\nThis commit establishes some centralized tests around exit handling so\nthat we can unify the behavior of our Rust frontend and `python`.\n\nThere are some added tests that use a value other than an integer\nor None for the exit code. The docs for sys.exit() say such a value\nis allowed. However, Mercurial currently crashes in this case. Upcoming\ncommits will teach Mercurial to handle these values.\n\nThis does introduce a few Python 3 test failures. However, this test\nalready has a few failures. And the failures being introduced should\nmostly go away with subsequent commits. So I think this is acceptable.","testPlan":"","lineCount":"91","dependsOn":[],"reviewers":["durin42","marmoute"],"ccs":["marmoute","mercurial-patches","durin42","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Baymax does not catch stuff in `Accepted` state, but this diff is over 2 years old, so resubmit if still relevant.","author":"marmoute","id":"126431","dateCreated":"1587571085","dateModified":"1587571085"},{"type":"reject","author":"marmoute","id":"126430","dateCreated":"1587571085","dateModified":"1587571085"},{"type":"comment","comment":"This LG, esp with D3445 which appears to be its child, but D3445 still needs rebased AFAICT","author":"durin42","id":"57781","dateCreated":"1527794332","dateModified":"1527794332"},{"type":"accept","author":"durin42","id":"57779","dateCreated":"1527794332","dateModified":"1527794332"},{"type":"comment","comment":">   > I generally like the direction of this series, but I think there's no point\n>   >  to extend Mercurial's exit code handling to support all weird Python types.\n>   >\n>   > Only ints and (None for 0) are ever valid.\n>   \n>   \n>   The reason I did this is because from the context or `rhg`, we don't have CPython's default exit handling to fall back on. Our choices are:\n>   \n>   1. Reimplement CPython's exit\/error handling in Rust\n>   2. Reimplement CPython's exit\/error handling in Python in dispatch [so the end state is more well-defined]\n>   3. Do something crude in `rhg` when we hit special cases that CPython would normally deal with.\n>   \n>   Since extensions could do weird things, I figured 2 was the best option.\n\nI don't fully understand the situation in `rhg`, but maybe we can instead\nfix `scmutil.callcatch()` to either translate non-int SystemExit to integer\nor raise ProgrammingError as a bad use of sys.exit() in hg. No SystemExit\nshould be raised outside of the callcatch().\n\nI'm against allowing command functions to return any objects other than\nint or None because it's useless.","author":"yuja","id":"56045","dateCreated":"1526104337","dateModified":"1526104337"},{"type":"comment","comment":">>! In D3444#54922, @yuja wrote:\n> I generally like the direction of this series, but I think there's no point\n> to extend Mercurial's exit code handling to support all weird Python types.\n> \n> Only ints and (None for 0) are ever valid.\n\nThe reason I did this is because from the context or `rhg`, we don't have CPython's default exit handling to fall back on. Our choices are:\n\n1. Reimplement CPython's exit\/error handling in Rust\n2. Reimplement CPython's exit\/error handling in Python in dispatch [so the end state is more well-defined]\n3. Do something crude in `rhg` when we hit special cases that CPython would normally deal with.\n\nSince extensions could do weird things, I figured 2 was the best option.\n\nBut I'll take a look at this series again and re-evaluate if we can simplify things. I just thought I'd brain dump on what I'm thinking.","author":"indygreg","id":"56014","dateCreated":"1526097317","dateModified":"1526097317"},{"type":"comment","comment":"I generally like the direction of this series, but I think there's no point\nto extend Mercurial's exit code handling to support all weird Python types.\n\nOnly ints and (None for 0) are ever valid.","author":"yuja","id":"54923","dateCreated":"1525609756","dateModified":"1525609756"},{"type":"update","diffId":"8459","author":"indygreg","id":"54808","dateCreated":"1525579871","dateModified":"1525579871"}],"dateCreated":"1525579871","dateModified":"1587571085","status":"Needs Revision"},{"id":"2873","callsign":"HG","title":"remotenames: add functionality to override -B flag of push","author":"pulkit","summary":"This patch adds a new config option which can be used to override the `-B` flag\nof push command. If config is set to true, changesets will be pushed to that\nbookmark on the server. This is equivalent to `--to` flag of remotenames and\ninfinitepush.\n\nAfter this patch if config is set to true, the behavior will be:\n\n  * Normal push without -B flag: no behavior change\n  * specifying one bookmark using -B flag: changesets will be pushed to that\n        bookmark on the server, as explained above. Bookmark pushed will be on\n        the head most revision of the changesets pushed.\n  * specifying multiple bookmarks using -B flag: no behavior change, the same\n        behavior as it's today without this config option\n  * specifying multiple topologcial heads to push: no behvaior change\n\nThere needs some extra logic to update the remotenames state locally after the\npush since we know that the bookmark will now be at a known updated location.","testPlan":"","lineCount":"356","dependsOn":[],"reviewers":["indygreg","marmoute"],"ccs":["mercurial-patches","marmoute","smf","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"Baymax does not catch stuff in `Accepted` state, but this diff is over 2 years old, so resubmit if still relevant.","author":"marmoute","id":"126426","dateCreated":"1587571035","dateModified":"1587571035"},{"type":"reject","author":"marmoute","id":"126425","dateCreated":"1587571035","dateModified":"1587571035"},{"type":"comment","comment":">>! In D2873#52100, @indygreg wrote:\n>>>! In D2873#52025, @smf wrote:\n>>>>! In D2873#52021, @indygreg wrote:\n>>> Looks good!\n>> \n>> I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.\n> \n> I think there's room for this feature to live outside of remotenames. But currently I think it is the best place for it, since remotenames is the closest thing we have to... tracking remote names. We can always alias the old config option in the future if we move this functionality elsewhere.\n\nOne of the biggest regrets I have about the original remotenames, is the modifying of push (and some default) behavior. The `--to` is small enough (and I guess fine enough) for now but I absolutely and strongly believe that all the other behavior modifications should stay in an out-of-core repo for now. My goal is to split my remotenames repo to be based off of core's remotenames (basically only having the behavior changing patches there).","author":"smf","id":"52118","dateCreated":"1523482769","dateModified":"1523482769"},{"type":"comment","comment":">>! In D2873#52025, @smf wrote:\n>>>! In D2873#52021, @indygreg wrote:\n>> Looks good!\n> \n> I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.\n\nI think there's room for this feature to live outside of remotenames. But currently I think it is the best place for it, since remotenames is the closest thing we have to... tracking remote names. We can always alias the old config option in the future if we move this functionality elsewhere.","author":"indygreg","id":"52100","dateCreated":"1523480112","dateModified":"1523480112"},{"type":"comment","comment":">>! In D2873#52021, @indygreg wrote:\n> Looks good!\n\nI'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.","author":"smf","id":"52026","dateCreated":"1523467971","dateModified":"1523467971"},{"type":"inline","comment":"Nit: \"exist\". This can be fixed in flight.","replyTo":null,"isNewFile":"1","line":"113","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7286","author":"indygreg","id":"52023","dateCreated":"1523467769","dateModified":"1523467769"},{"type":"comment","comment":"Looks good!","author":"indygreg","id":"52022","dateCreated":"1523467769","dateModified":"1523467769"},{"type":"accept","author":"indygreg","id":"52021","dateCreated":"1523467769","dateModified":"1523467769"},{"type":"comment","comment":"A gentle reminder for reviewing this series. If this config option gets in, we can use it in infinitepush extension too where for now we have overridden `-B` flag in a hacky way.","author":"pulkit","id":"48737","dateCreated":"1522601487","dateModified":"1522601487"},{"type":"update","diffId":"7286","author":"pulkit","id":"47560","dateCreated":"1522064849","dateModified":"1522064849"},{"type":"inline","comment":"What happens if we're pushing multiple heads? I suspect this will choose a head\/revision arbitrarily - maybe depending on the `-r` arguments to `hg push`.\n\nI think we need to validate that the outgoing revs are in a single DAG head and we should then pick the rev that is the DAG head.\n\nPlease add test coverage for multiple `-r` arguments and `-r` arguments that resolve to multiple heads.","replyTo":null,"isNewFile":"1","line":"99","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7249","author":"indygreg","id":"47382","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"inline","comment":"Nit: what is `--create`?","replyTo":null,"isNewFile":"1","line":"101","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7249","author":"indygreg","id":"47381","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"inline","comment":"Strictly speaking, we should probably wrap `exchange._pushdiscoverybookmarks` so other extensions can get involved. But I think this is fine.","replyTo":null,"isNewFile":"1","line":"287","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7249","author":"indygreg","id":"47380","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"comment","comment":"I'm happy with this feature.\n\nBut the code needs work around multiple revisions\/heads before it can be queued.","author":"indygreg","id":"47379","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"reject","author":"indygreg","id":"47378","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"update","diffId":"7249","author":"pulkit","id":"47274","dateCreated":"1521704112","dateModified":"1521704112"},{"type":"update","diffId":"7103","author":"pulkit","id":"46423","dateCreated":"1521448561","dateModified":"1521448561"},{"type":"comment","comment":"I am not sure the functionality and config names should go to core or not, so I have introduced them in this extension. Also suggestions for better config names are welcome.","author":"pulkit","id":"46265","dateCreated":"1521212432","dateModified":"1521212432"},{"type":"update","diffId":"7061","author":"pulkit","id":"46148","dateCreated":"1521121763","dateModified":"1521121763"}],"dateCreated":"1521121763","dateModified":"1587571035","status":"Needs Revision"},{"id":"2875","callsign":"HG","title":"remotenames: introduce a config option to allow creation of remote bookmarks","author":"pulkit","summary":"This patch introduces another config option which if set to true, we can create\nnew bookmarks on the server using push command. An earlier patch added\ncapability to push to a certain bookmark on the server. If bookmark was not\nalready present on the server, we errored out. With\nremotenames.createremotebookmark config set, the push will create that bookmark\non the server.\n\nThis series serves as a great feature for people who use bookmarks as after this\nyou can push changesets to a bookmark which does not exists locally. In other\nwords, you can push your changesets to a bookmark without having it locally.\n\nThis series will help people in having a non-local bookmark workflow involving\nremotenames.\n\nThe functionality added in this patch is equivalent to --create flag to push\ncommand added by hgremotenames extension.","testPlan":"","lineCount":"166","dependsOn":[],"reviewers":["indygreg","marmoute"],"ccs":["mercurial-patches","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"Baymax does not catch stuff in `Accepted` state, but this diff is over 2 years old, so resubmit if still relevant.","author":"marmoute","id":"126421","dateCreated":"1587571026","dateModified":"1587571026"},{"type":"reject","author":"marmoute","id":"126420","dateCreated":"1587571026","dateModified":"1587571026"},{"type":"accept","author":"indygreg","id":"52032","dateCreated":"1523468132","dateModified":"1523468132"},{"type":"update","diffId":"7288","author":"pulkit","id":"47564","dateCreated":"1522064875","dateModified":"1522064875"},{"type":"update","diffId":"7251","author":"pulkit","id":"47276","dateCreated":"1521704137","dateModified":"1521704137"},{"type":"update","diffId":"7105","author":"pulkit","id":"46425","dateCreated":"1521448583","dateModified":"1521448583"},{"type":"update","diffId":"7063","author":"pulkit","id":"46164","dateCreated":"1521121786","dateModified":"1521121786"}],"dateCreated":"1521121786","dateModified":"1587571027","status":"Needs Revision"},{"id":"7577","callsign":"HG","title":"hg-core: implement Mercurial's config file discovery logic","author":"indygreg","summary":"The imported Facebook code for locating Mercurial config files\ndiffered from what Mercurial itself does. This commit modifies the\nlogic to match what Mercurial currently does.\n\nAs part of this, we added some crate dependencies. We could probably\navoid these dependencies if we want. But these crates are quite popular\nand useful and I imagine we'll end up using them eventually.\n\nWe should probably add some test coverage of this code...","testPlan":"","lineCount":"148","dependsOn":["7576"],"reviewers":["kevincox","Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126413","dateCreated":"1587570782","dateModified":"1587570782"},{"type":"reject","author":"baymax","id":"126412","dateCreated":"1587570782","dateModified":"1587570782"},{"type":"accept","author":"Alphare","id":"111521","dateCreated":"1575896924","dateModified":"1575896924"},{"type":"inline","comment":"I believe this can just be `.flatten()`.","replyTo":null,"isNewFile":"1","line":"145","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/config.rs","diffId":"18544","author":"kevincox","id":"111453","dateCreated":"1575894221","dateModified":"1575894221"},{"type":"accept","author":"kevincox","id":"111452","dateCreated":"1575894221","dateModified":"1575894221"},{"type":"update","diffId":"18544","author":"indygreg","id":"111399","dateCreated":"1575759436","dateModified":"1575759436"},{"type":"update","diffId":"18537","author":"indygreg","id":"111349","dateCreated":"1575749873","dateModified":"1575749873"}],"dateCreated":"1575749873","dateModified":"1587570782","status":"Needs Revision"},{"id":"7717","callsign":"HG","title":"rust-discovery: restoring add_missing cheap early return","author":"gracinet","summary":"In case the iterator of missing revisions argument turns out\nto be empty, we need to refrain from computing the undecided\nset. This way, we'll benefit from subsequent add_common_revisions\nuntil there is an actually meaningful add_missing_revisions.\n\nTo do this with the typestate pattern, that means the early\nreturn has to happen before potential transition into an\nWithUndecided","testPlan":"","lineCount":"23","dependsOn":["7716"],"reviewers":["Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126409","dateCreated":"1587570781","dateModified":"1587570781"},{"type":"reject","author":"baymax","id":"126408","dateCreated":"1587570781","dateModified":"1587570781"},{"type":"accept","author":"Alphare","id":"114421","dateCreated":"1578044801","dateModified":"1578044801"},{"type":"update","diffId":"18925","author":"gracinet","id":"113690","dateCreated":"1577195395","dateModified":"1577195395"}],"dateCreated":"1577195395","dateModified":"1587570781","status":"Needs Revision"},{"id":"7718","callsign":"HG","title":"rust-directory: simplify bidirectional sampling","author":"gracinet","summary":"Thanks to the typestate pattern, we don't have a\ncomplicated management of borrows to perform in\nthat method with the early return condition and\nthe comment was just obsolete.","testPlan":"","lineCount":"9","dependsOn":["7717"],"reviewers":["Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126405","dateCreated":"1587570780","dateModified":"1587570780"},{"type":"reject","author":"baymax","id":"126404","dateCreated":"1587570780","dateModified":"1587570780"},{"type":"accept","author":"Alphare","id":"114422","dateCreated":"1578044870","dateModified":"1578044870"},{"type":"update","diffId":"18926","author":"gracinet","id":"113698","dateCreated":"1577195401","dateModified":"1577195401"}],"dateCreated":"1577195401","dateModified":"1587570780","status":"Needs Revision"},{"id":"7719","callsign":"HG","title":"rust-discovery: children cache as typestate transition","author":"gracinet","summary":"As of 8c9a6adec67a, we were actually using\nthe children cache right away in `add_missing_revisions`,\nthe method that also triggers the undecided set computation\n(see that changeset description for the corresponding\nperformance discussion).\n\nThis means we don't need a third typestate for the children\ncache: `WithUndecided` can always have it.\n\nIt is clear that `compute_children_cache` does not have\nto be tied to the `WithUndecided` struct anymore. We may\nmove it to `hg::dagops` in a later move.","testPlan":"","lineCount":"63","dependsOn":["7718"],"reviewers":["Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126401","dateCreated":"1587570779","dateModified":"1587570779"},{"type":"reject","author":"baymax","id":"126400","dateCreated":"1587570779","dateModified":"1587570779"},{"type":"accept","author":"Alphare","id":"114423","dateCreated":"1578045124","dateModified":"1578045124"},{"type":"update","diffId":"18927","author":"gracinet","id":"113706","dateCreated":"1577195409","dateModified":"1577195409"}],"dateCreated":"1577195409","dateModified":"1587570779","status":"Needs Revision"},{"id":"7720","callsign":"HG","title":"rust-discovery: moved some methods to the wrapper enum","author":"gracinet","summary":"In the primary switch to the typestate pattern, these\nmethods have been kept on the `WithUndecided` struct, that\nhad most of the original methods of `PartialDiscovery`, so\nthat the change would be readable.\n\nBut we feel it makes more sense to have them on the wrapper\nenum.\n\n`common_heads` would also be a candidate for a last stage method,\nwe wouldn't need that lenghty warning docstring that it's not\nrelevant if `is-complete` is `true`","testPlan":"","lineCount":"44","dependsOn":["7719"],"reviewers":["Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126397","dateCreated":"1587570778","dateModified":"1587570778"},{"type":"reject","author":"baymax","id":"126396","dateCreated":"1587570778","dateModified":"1587570778"},{"type":"accept","author":"Alphare","id":"114424","dateCreated":"1578045272","dateModified":"1578045272"},{"type":"update","diffId":"18928","author":"gracinet","id":"113715","dateCreated":"1577195416","dateModified":"1577195416"}],"dateCreated":"1577195416","dateModified":"1587570778","status":"Needs Revision"},{"id":"7721","callsign":"HG","title":"rust-discovery: postponing random generator init","author":"gracinet","summary":"This is an example of the benefits we get with the\ntypestape pattern: we can cleanly postpone the\nseeding and initialisation of the random generator.\n\nThis makes the `default()` method a bit cheaper. Its point\nis that its output is a placeholder not meand to be really used,\nbut if that happened, it would now be with the knowledge that\nthe seed hasn't been initialized (and possible seeding after\nmorphing into a discovery with undecided set)","testPlan":"","lineCount":"41","dependsOn":["7720"],"reviewers":["Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126393","dateCreated":"1587570777","dateModified":"1587570777"},{"type":"reject","author":"baymax","id":"126392","dateCreated":"1587570777","dateModified":"1587570777"},{"type":"accept","author":"Alphare","id":"114425","dateCreated":"1578045385","dateModified":"1578045385"},{"type":"update","diffId":"18929","author":"gracinet","id":"113723","dateCreated":"1577195423","dateModified":"1577195423"}],"dateCreated":"1577195423","dateModified":"1587570777","status":"Needs Revision"},{"id":"7722","callsign":"HG","title":"rust-discovery: simplifying add_missing_revisions()","author":"gracinet","summary":"with the removal of the various ensure() it's become\nclear that this doesn't have error cases any more, and we didn't\nneed the full match at the end.","testPlan":"","lineCount":"21","dependsOn":["7721"],"reviewers":["Alphare","baymax"],"ccs":["mercurial-patches","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"126389","dateCreated":"1587570776","dateModified":"1587570776"},{"type":"reject","author":"baymax","id":"126388","dateCreated":"1587570776","dateModified":"1587570776"},{"type":"accept","author":"Alphare","id":"114426","dateCreated":"1578045432","dateModified":"1578045432"},{"type":"update","diffId":"18930","author":"gracinet","id":"113731","dateCreated":"1577195430","dateModified":"1577195430"}],"dateCreated":"1577195430","dateModified":"1587570776","status":"Needs Revision"},{"id":"6846","callsign":"HG","title":"packaging: script the building of a MacOS installer using a custom python","author":"mharbison72","summary":"The intent here is to get away from relying on system python (which is going\naway in 10.16), so that an installer can easily be built to work on multiple\nversions of the OS.  10.9 was chosen as the minimum platform here because that's\nthe SDK needed to notarize, and also what the binary python installer targets.\nA lot of this was adapted from the script that builds the TortoiseHg DMG.\n\nThere's a useful thg customization (not duplicated here), which extends\n`sys.path` to include $HOME\/Library\/Python\/2.7\/lib\/python\/site-packages, because\nthere's no way to add to the bundled python after the app is signed.  As it\nstands now, this installation won't see that, but does see\n$HOME\/.local\/lib\/python2.7\/site-packages, and the bundled `pip` will install\nthere with `--user`.  It does seem like only seeing the second `--user` location\nwill get confusing, especially since the current behavior is that\n`pip install --user ...` just works for `pip` in PATH.\n\nThe prerequisite is to have python3 to run the script, and a working python2\nwith docutils installed to feed to the script.  (The latter is used to build and\ninstall the documentation for Mercurial without polluting the python distro to\nbe packaged, so maybe we can use python3 there.)\n\nThe general flow is to download, build and install OpenSSL off to the side, and\nthen use that to download, build and install Python to a separate staging area.\nThe certifi package is bundled for the root certificates.  I'm not an expert in\nwhat OpenSSL compilation options should be used, so if there's a way to tighten\nthings up, let me know.\n\nI don't like how the other packaging scripts assume an existing path on the\nsystem, so this uses the build directory to stage the Python and OpenSSL builds.\nThe existing system python installer stages in `build\/mercurial`, but this\nbuilds Mercurial into the staged python directory.  (That path includes version\ninfo, so it shouldn't be much to add python3 support and build both at the same\ntime.)  I also wasn't sure where to stash the downloads (they seem somewhat\nuseful to cache), so I stuffed them into the packages directory (which gets\nclobbered by `make clean`).\n\nTo distinguish from the system python installer (and with an eye towards\npython3), `-py2.7` is added after the Mercurial version to the file name.\nAltogether, this takes about 10 minutes to build on a 2018 Mac Mini.\n\nThere's additional followup work to do, in addition to the obvious py3 support-\nthe readme still mentions depending on system python, and this could probably be\ndriven by the makefile as a separate target.  It should be trivial to sign the\nbinaries and installer, and slightly less trivial to notarize the *.pkg, but\ndefinitely doable.  The files in the final *.pkg can be listed like so:\n\n    pkgutil --payload-files dist\/Mercurial-*.pkg\n\nLooking at that, there's probably a bunch of junk that can be removed:\n\n    - include\/\n    - distutils\/tests\/\n    - lib-tk\/test\/\n    - ctypes\/test\/,\n    - unittest\n    - test\n    - lib2to3\n    - idle\n    - pydoc\n\nI didn't see config options for that, and maybe it isn't worth it.  The\ninstaller ends up around 39MB.","testPlan":"","lineCount":"364","dependsOn":[],"reviewers":[],"ccs":["indygreg","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6846#126171, @marmoute wrote:\n> So as I understand this is not ready to land and should be moved to change-requested (or change planned), right ?\n\nYeah, I'll move this out of the way, and can abandon it when PyOxidizer builds are in place.","author":"mharbison72","id":"126173","dateCreated":"1587149777","dateModified":"1587149777"},{"type":"plan-changes","author":"mharbison72","id":"126172","dateCreated":"1587149777","dateModified":"1587149777"},{"type":"comment","comment":"So as I understand this is not ready to land and should be moved to change-requested (or change planned), right ?","author":"marmoute","id":"126171","dateCreated":"1587148771","dateModified":"1587148771"},{"type":"comment","comment":">>! In D6846#124054, @marmoute wrote:\n> What's the status of this ? @mharbison72  id the linking problem got solved ?\n\nI've been too busy to get back to this, and probably won't for the short term, anyway.\n\nIt would probably also be a good to have a general idea when we drop py2 completely.  I'd be content leaving py2 around for awhile for various reasons, but I don't want to sink a bunch of time into something that lasts for one release.  (I think a PyOxidizer build would end up being a lot different looking than this.)","author":"mharbison72","id":"124250","dateCreated":"1584759006","dateModified":"1584759006"},{"type":"comment","comment":"What's the status of this ? @mharbison72  id the linking problem got solved ?","author":"marmoute","id":"124054","dateCreated":"1584659831","dateModified":"1584659831"},{"type":"inline","comment":"From the scripts used to build TortoiseHg on Mac, and the OpenSSL wiki:\n\nhttps:\/\/bitbucket.org\/Weeds2000\/tortoisehg-osx-build-scripts\/src\/e459bb439730d7e7e3a4b8c474f74aab164d6c9f\/toolchain\/receipts\/openssl.sh#lines-41\n\nhttps:\/\/wiki.openssl.org\/index.php\/Compilation_and_Installation#OS_X","replyTo":"120515","isNewFile":"1","line":"54","lineLength":"0","path":"contrib\/packaging\/hgpackaging\/python.py","diffId":"16526","author":"mharbison72","id":"120558","dateCreated":"1581526775","dateModified":"1581526775"},{"type":"inline","comment":"The original shebang line was much longer, so after writing it out with the shorter one, I think this was meant to trim the file. too the proper content.","replyTo":"120517","isNewFile":"1","line":"170","lineLength":"0","path":"contrib\/packaging\/macosx\/build.py","diffId":"16526","author":"mharbison72","id":"120557","dateCreated":"1581526775","dateModified":"1581526775"},{"type":"comment","comment":">>! In D6846#120513, @indygreg wrote:\n> macOS supports a `@loader_path` and related magic tokens in rpath to load libraries relative to the current binary. See e.g. https:\/\/blogs.oracle.com\/dipol\/dynamic-libraries,-rpath,-and-mac-os and https:\/\/medium.com\/@donblas\/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172 for examples.\n\nI saw those, thanks.  I guess what's confusing is I don't see RPATH being configured when building OpenSSL for the TortoiseHg build, nor do I see it being overwritten when running py2app.  I also interpreted this to mean that is should be automatic on Mac, but I guess not:\n\nhttps:\/\/wiki.openssl.org\/index.php\/Compilation_and_Installation#Using_RPATHs","author":"mharbison72","id":"120556","dateCreated":"1581526775","dateModified":"1581526775"},{"type":"inline","comment":"`fp.truncate()`?","replyTo":null,"isNewFile":"1","line":"170","lineLength":"0","path":"contrib\/packaging\/macosx\/build.py","diffId":"16526","author":"indygreg","id":"120517","dateCreated":"1581476182","dateModified":"1581476182"},{"type":"inline","comment":"I _think_ we also want `--enable-lto` for more speed wins.","replyTo":null,"isNewFile":"1","line":"120","lineLength":"0","path":"contrib\/packaging\/hgpackaging\/python.py","diffId":"16526","author":"indygreg","id":"120516","dateCreated":"1581476182","dateModified":"1581476182"},{"type":"inline","comment":"Where did you get this line and `enable-cms` from?","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"contrib\/packaging\/hgpackaging\/python.py","diffId":"16526","author":"indygreg","id":"120515","dateCreated":"1581476182","dateModified":"1581476182"},{"type":"inline","comment":"1.0.2u is out and should be used.","replyTo":null,"isNewFile":"1","line":"29","lineLength":"0","path":"contrib\/packaging\/hgpackaging\/downloads.py","diffId":"16526","author":"indygreg","id":"120514","dateCreated":"1581476182","dateModified":"1581476182"},{"type":"comment","comment":"macOS supports a `@loader_path` and related magic tokens in rpath to load libraries relative to the current binary. See e.g. https:\/\/blogs.oracle.com\/dipol\/dynamic-libraries,-rpath,-and-mac-os and https:\/\/medium.com\/@donblas\/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172 for examples.","author":"indygreg","id":"120513","dateCreated":"1581475710","dateModified":"1581475710"},{"type":"comment","comment":"Ha, ok.","author":"marmoute","id":"119491","dateCreated":"1580979783","dateModified":"1580979783"},{"type":"comment","comment":">>! In D6846#119328, @marmoute wrote:\n> are we talking about python library or compiled library ? Go you have any \"empty\" item in the various PATH used for the build ?\n\nSee https:\/\/phab.mercurial-scm.org\/D6846#100512.\n\nI'm not sure what you mean about empty items.  The build directory is out of the way, not on PATH.  It's just that `_ssl.so` wants to load OpenSSL libraries from the path where they were built.  It actually works fine after installing- until you do a `make clean`, which is how I noticed the problem.","author":"mharbison72","id":"119482","dateCreated":"1580956098","dateModified":"1580956098"},{"type":"comment","comment":"are we talking about python library or compiled library ? Go you have any \"empty\" item in the various PATH used for the build ?","author":"marmoute","id":"119328","dateCreated":"1580918617","dateModified":"1580918617"},{"type":"comment","comment":">>! In D6846#118733, @marmoute wrote:\n> What's the latest with this diff ? It seems to still be a work in progress. Should it be in the \"need-review\" state?\n\nThe hangup here is that the installed code seems to want to look in the path where it was built to load libraries.  I have no idea why.  It would be good if somebody figured out why, because I have a similar problem with the thg build on Mac.  (But unlike here, that's not fatal because it falls back to a library inside the bundle.)\n\nMy thought with this was to be able to build an official py2 installer that worked on more than the very latest platform.  But I also thought that we would hang on to py2 for awhile.  If we're not, then this probably isn't worth pursuing, assuming PyOxidizer works out on OS X (so far, so good).  I'm not so excited about dropping py2 because of the amount of work still needed on hg on Windows, thg on Windows and Mac, and the packaging on both.  But 10.16 will remove all builtin python, so something will probably need to be done one way or the other by September or so.","author":"mharbison72","id":"118786","dateCreated":"1580448255","dateModified":"1580448255"},{"type":"comment","comment":"What's the latest with this diff ? It seems to still be a work in progress. Should it be in the \"need-review\" state?","author":"marmoute","id":"118733","dateCreated":"1580408474","dateModified":"1580408474"},{"type":"comment","comment":">>! In D6846#100478, @mharbison72 wrote:\n> This seems to work (though the shebang line hack is painful)- until the original python build directory is deleted.  Then a lot of things complain about unsupported hash type for md5 and sha{1,224,256,384,512}.  Other modules like `json` can be imported with the installed python executable.  I grepped around for the build directory, and it is in a bunch of *.so files (though this could be `__FILE__` for all I know).  Any ideas?\n\nSo, the problem here is that openssl libraries are being built and installed with the temporary install path, and the `_ssl.so` module is expecting to find them there.  I tried a custom Setup.local that statically links `_ssl.so` against openssl before configuring python, but the build summary said dependencies were missing to build `_ssl` (among other things).  For some reason, the resulting build still seemed to be able to talk to https servers.  `help(_ssl)` said it was builtin, whereas `help(_ssl)` on the original build mentioned openssl (IIRC).\n\nThe `_ssl.so` module in the thg app has `@executable_path` in the library name, so that's why that works.  I also tried messing with `@rpath`, but I can't get that working either.  I'm not sure what else to try.","author":"mharbison72","id":"100512","dateCreated":"1568414255","dateModified":"1568414255"},{"type":"comment","comment":"This seems to work (though the shebang line hack is painful)- until the original python build directory is deleted.  Then a lot of things complain about unsupported hash type for md5 and sha{1,224,256,384,512}.  Other modules like `json` can be imported with the installed python executable.  I grepped around for the build directory, and it is in a bunch of *.so files (though this could be `__FILE__` for all I know).  Any ideas?","author":"mharbison72","id":"100478","dateCreated":"1568327294","dateModified":"1568327294"},{"type":"update","diffId":"16526","author":"mharbison72","id":"100472","dateCreated":"1568326880","dateModified":"1568326880"}],"dateCreated":"1568326880","dateModified":"1587149777","status":"Changes Planned"},{"id":"7295","callsign":"HG","title":"pytype: add a (very slow) test that executes pytype","author":"durin42","summary":"This doesn't actually pass yet, but I wanted to share it early so\nothers can play with pytype.","testPlan":"","lineCount":"38","dependsOn":["7384"],"reviewers":["indygreg","marmoute"],"ccs":["quark","marmoute","mharbison72","dlax","indygreg","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"According to IRC discussion with Augie, this is not ready yet.","author":"marmoute","id":"126169","dateCreated":"1587148569","dateModified":"1587148569"},{"type":"reject","author":"marmoute","id":"126168","dateCreated":"1587148569","dateModified":"1587148569"},{"type":"comment","comment":"> No, initially because I'd never heard of it, but now because I don't want to deal with ocaml. :)\n\nThe `pip install` version ships with a pre-compiled binary so an ocaml compiler is not needed.\n\n>  I'm dubious that it's doing anywhere near the checking of pytype if it manages to run to completion without errors. What does the output look like?\n\nGood question. I wasn't aware about the differences. I read pytype's README and the examples apply to pyre too. Pytype does type inference while pyre only checks functions that already have type annotations.\n\n\nPyre does complete ([output](https:\/\/bpaste.net\/7JCQ)). I wasn't able to get pytype past 44\/251 ([output](https:\/\/bpaste.net\/CLEQ)). For files with type annotations like `mail.py`, it seems pyre output is useful:\n\n```\n# on commit d844202324924919bc517691052d39c520e077eb\nmercurial\/mail.py:57:4 Inconsistent override [15]: `mail.STARTTLS.starttls` overrides method defined in `smtplib.SMTP` inconsistently. The overriding method is not annotated but should return a subtype of `typing.Tuple[int, bytes]`.\nmercurial\/mail.py:387:22 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.\nmercurial\/mail.py:392:28 Incompatible parameter type [6]: Expected `bytes` for 2nd anonymous parameter to call `_encode` but got `Union[bytes, str]`.\nmercurial\/mail.py:394:33 Incompatible parameter type [6]: Expected `bytes` for 1st anonymous parameter to call `encoding.strfromlocal` but got `Union[bytes, str]`.\nmercurial\/mail.py:397:35 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.\nmercurial\/mail.py:399:4 Incompatible variable type [9]: addr is declared to have type `str` but is used as type `bytes`.\nmercurial\/mail.py:402:30 Incompatible parameter type [6]: Expected `typing.Optional[str]` for 1st anonymous parameter to call `str.split` but got `bytes`.\nmercurial\/mail.py:405:8 Incompatible variable type [9]: addr is declared to have type `str` but is used as type `bytes`.\nmercurial\/mail.py:414:63 Incompatible parameter type [6]: Expected `bytes` for 1st anonymous parameter to call `encoding.strfromlocal` but got `str`.\nmercurial\/mail.py:417:31 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.\nmercurial\/mail.py:426:30 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.\nmercurial\/mail.py:446:22 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.\nmercurial\/mail.py:499:52 Incompatible parameter type [6]: Expected `Union[email.header.Header, str]` for 1st anonymous parameter to call `email.header.decode_header` but got `Union[bytes, email.header.Header]`.\n```\n\nIt seems to me that a combined approach might be interesting - use pytype to generate `pyi` files and pyre for faster checking.","author":"quark","id":"118882","dateCreated":"1580500731","dateModified":"1580500803"},{"type":"comment","comment":">>! In D7295#118785, @quark wrote:\n> Have `pyre` been considered?\n\nNo, initially because I'd never heard of it, but now because I don't want to deal with ocaml. :)\n\n> It seems `pyre` only takes 10 seconds to check all the `.py` files.\n> \n> EDIT: 10s on a machine with many CPU cores. 1 minute on laptop.\n\nI'm dubious that it's doing anywhere near the checking of pytype if it manages to run to completion without errors. What does the output look like?","author":"durin42","id":"118820","dateCreated":"1580483967","dateModified":"1580483967"},{"type":"comment","comment":"Have `pyre` been considered? It seems `pyre` only takes 10 seconds to check all the `.py` files.\n\nEDIT: 10s on a machine with many CPU cores. 1 minute on laptop.","author":"quark","id":"118785","dateCreated":"1580447745","dateModified":"1580449193"},{"type":"comment","comment":"This seems useful, and the stabilisation seems to take a long while. Maybe we could take it in its current state (with \"expected\" broken output) and iterate from there. With the test in the repo.\n\nWhat do you all think ?","author":"marmoute","id":"118743","dateCreated":"1580409284","dateModified":"1580409284"},{"type":"comment","comment":">>! In D7295#110254, @mharbison72 wrote:\n>>>! In D7295#107482, @indygreg wrote:\n>> Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?\n> \n> It takes 15-20 minutes on a 2018 Mac mini.  In addition to the disabled files here, I've disabled:\n> \n>     mercurial\/httppeer.py\n>     mercurial\/repoview.py\n>     mercurial\/localrepo.py\n>     mercurial\/revlog.py\n>     mercurial\/merge.py\n>     mercurial\/testing\/storage.py\n> \n> But I've also added back these, and sprinkled various disable comments around:\n> \n>     mercurial\/bundlerepo.py\n>     mercurial\/error.py\n>     mercurial\/exchange.py\n>     mercurial\/policy.py\n>     mercurial\/pycompat.py\n>     mercurial\/scmwindows.py\n>     mercurial\/windows.py\n>     mercurial\/wireprotoframing.py\n> \n> Even with the state files, it seems to take 10-15 minutes or so.\n\nOoh, can you send your extra suppressions? For the most part I've been tackling this as a side project when I'm waiting on compiles.\n\nAs to doing individual files: that's well and good, and might be a viable approach for mypy. That said, my sense has been that mypy is faster and significantly less useful, since we don't get cross-file analysis of what's going on. I _think_ pytype gets faster as we add more annotations, so my rough thought thus far as been to try and get some subset of the codebase clean, transitively, and then try to start stamping some types on important functions and interfaces to constrain things. Where I'd _really_ like to get is to be able to migrate the `@command` decorators and friends to use strings instead of bytes, and be able to recommend typechecking as a way for extension authors to clean things up, but that'll take a while.","author":"durin42","id":"110437","dateCreated":"1574531296","dateModified":"1574531296"},{"type":"comment","comment":">>! In D7295#107482, @indygreg wrote:\n> Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?\n\nIt takes 15-20 minutes on a 2018 Mac mini.  In addition to the disabled files here, I've disabled:\n\n    mercurial\/httppeer.py\n    mercurial\/repoview.py\n    mercurial\/localrepo.py\n    mercurial\/revlog.py\n    mercurial\/merge.py\n    mercurial\/testing\/storage.py\n\nBut I've also added back these, and sprinkled various disable comments around:\n\n    mercurial\/bundlerepo.py\n    mercurial\/error.py\n    mercurial\/exchange.py\n    mercurial\/policy.py\n    mercurial\/pycompat.py\n    mercurial\/scmwindows.py\n    mercurial\/windows.py\n    mercurial\/wireprotoframing.py\n\nEven with the state files, it seems to take 10-15 minutes or so.","author":"mharbison72","id":"110254","dateCreated":"1574462605","dateModified":"1574462605"},{"type":"update","diffId":"18242","author":"durin42","id":"109676","dateCreated":"1574187225","dateModified":"1574187225"},{"type":"inline","comment":"Needs a trailing slash here.","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"tests\/test-check-pytype.t","diffId":"18104","author":"mharbison72","id":"109670","dateCreated":"1574180889","dateModified":"1574180889"},{"type":"update","diffId":"18104","author":"durin42","id":"108811","dateCreated":"1573765830","dateModified":"1573765830"},{"type":"update","diffId":"18072","author":"durin42","id":"108536","dateCreated":"1573703500","dateModified":"1573703500"},{"type":"comment","comment":"This can't land per commit message, so setting status accordingly.\n\nI'm extremely supportive of adding type checking, whether it be pytype or mypy. I don't think it matters much. And TBH I wouldn't be surprised if we end up with both once we drop Python 2 support and start using inline annotations heavily!\n\nAs for how to start testing, I think we should do this like Python 3 and try to make individual files \"clean.\" Maintain a list of clean files and we ratchet from there.\n\nSince type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?","author":"indygreg","id":"107482","dateCreated":"1573231954","dateModified":"1573231954"},{"type":"reject","author":"indygreg","id":"107481","dateCreated":"1573231954","dateModified":"1573231954"},{"type":"update","diffId":"17665","author":"durin42","id":"106664","dateCreated":"1573081192","dateModified":"1573081192"}],"dateCreated":"1573081192","dateModified":"1587148569","status":"Needs Revision"},{"id":"8352","callsign":"HG","title":"extensions: don't crash if __file__ not defined","author":"indygreg","summary":"This attribute isn't present in PyOxidizer when loading modules\nfrom memory.\n\nBefore, this code was crashing under PyOxidizer. After, it simply\nyields unexpected results. This still isn't great (we need a better\nmechanism to discover extensions when modules aren't loaded from\nthe filesystem). But it is strictly better since we no longer\nget tracebacks.","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"inline","comment":"Maybe mention that the result if \"wrong\" here? If I understand you commit message fine, this change does not make this code work as expected. It only prevent a crash. If I got this right, it would be useful to mention it in the comment.","replyTo":null,"isNewFile":"1","line":"709","lineLength":"0","path":"mercurial\/extensions.py","diffId":"20927","author":"marmoute","id":"124721","dateCreated":"1585729041","dateModified":"1585729041"},{"type":"reject","author":"marmoute","id":"124720","dateCreated":"1585729041","dateModified":"1585729041"},{"type":"update","diffId":"20927","author":"indygreg","id":"124704","dateCreated":"1585711761","dateModified":"1585711761"}],"dateCreated":"1585711761","dateModified":"1585729041","status":"Needs Revision"},{"id":"7296","callsign":"HG","title":"pycompat: kludge around pytype being confused by __new__","author":"durin42","summary":"Credit to Yuya for the idea of annotating the class as though it was a\ncallable. I honestly didn't expect this to work, but it does!\n\nWe annotate this awkwardly on a name alias of the type because putting\nthe annotation directly on the `class ...:` line as a comment breaks\nblack and I don't want to go down that rabbit hole.","testPlan":"","lineCount":"17","dependsOn":[],"reviewers":["indygreg","dlax"],"ccs":["marmoute","yuja","mjpieters","dlax","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"I'd like to get back to pytyping all the things, but I can't justify spending more time on it. If someone else wants to push things forward I'll gladly provide some mentorship.","author":"durin42","id":"124131","dateCreated":"1584719973","dateModified":"1584719973"},{"type":"plan-changes","author":"durin42","id":"124130","dateCreated":"1584719973","dateModified":"1584719973"},{"type":"comment","comment":"This is the last series stuck at the bottom of yadda.\n\nIt feels like it is still a work in progress, @durin42 can you clarify the status of this and possibly move it out of need-review if it is still a work in progress ? ","author":"marmoute","id":"124053","dateCreated":"1584659695","dateModified":"1584659695"},{"type":"comment","comment":"The status of this is unclear ? Are we waiting on:\n\n1) a the right way to do it in our codebase?\n2) a fix in pytype?\n3) a fix in python?\n4) something else?","author":"marmoute","id":"118737","dateCreated":"1580409000","dateModified":"1580409000"},{"type":"comment","comment":">>! In D7296#109684, @dlax wrote:\n> Looking closer at the error above, it mentions `bytestr.__init__`, not `__new__` (and there is in fact no type annotation for `__new__` in [typeshed](https:\/\/github.com\/python\/typeshed\/blob\/34d68ab0a2117a08fa221d3a10884f35cacf2cdc\/stdlib\/2and3\/builtins.pyi#L559)). \n\nhttps:\/\/github.com\/python\/typeshed\/issues\/2630","author":"dlax","id":"109688","dateCreated":"1574194446","dateModified":"1574194446"},{"type":"inline","comment":"Now the `type: ` is missing, so the comment is ignored.\n\nAdding it, `pytype mercurial\/pycompat.py` gives:\n```\nmercurial\/pycompat.py\", line 305, in <module>: Invalid type comment: Callable[[Union[bytes, str]], bytestr] [invalid-type-comment]\n  Name 'bytestr' is not defined\n```\nhence the kind of trick I suggested in my first comment on this line.","replyTo":null,"isNewFile":"1","line":"305","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18243","author":"dlax","id":"109687","dateCreated":"1574194206","dateModified":"1574194206"},{"type":"comment","comment":">>! In D7296#109683, @durin42 wrote:\n>>>! In D7296#109672, @dlax wrote:\n>> Sorry, still not ok afaict :\/\n> \n> So, I tried fixing this and it actually made things worse? dagparser.py no longer typechecks if I correct the syntax? Try the pytype invocation from the test at the end of the series and you'll see what I mean.\n\nOk, trying `pytype mercurial\/dagparser.py` I get a couple of those errors:\n```\nFile \"...\/mercurial\/dagparser.py\", line 172, in parsedag: Function bytestr.__init__ was called with the wrong arguments [wrong-arg-types]\n  Expected: (self, ints: Iterable[int])\n  Actually passed: (self, ints: str)\n```\n\nMy point was that we need to keep \"mercurial\/pycompat.py\" passing pytype before considering modules it depends on. Once the missing `type: ` is added and bytestr <-> _bytestr trick applied, it's okay but the error in dagparser.py persists...\nLooking closer at the error above, it mentions `bytestr.__init__`, not `__new__` (and there is in fact no type annotation for `__new__` in [typeshed](https:\/\/github.com\/python\/typeshed\/blob\/34d68ab0a2117a08fa221d3a10884f35cacf2cdc\/stdlib\/2and3\/builtins.pyi#L559)). So I suspect the \"Callable\" trick is not enough and we'd need a workaround similar to da925257 by @yuja . ","author":"dlax","id":"109686","dateCreated":"1574194206","dateModified":"1574194206"},{"type":"comment","comment":">>! In D7296#109672, @dlax wrote:\n> Sorry, still not ok afaict :\/\n\nSo, I tried fixing this and it actually made things worse? dagparser.py no longer typechecks if I correct the syntax? Try the pytype invocation from the test at the end of the series and you'll see what I mean.","author":"durin42","id":"109683","dateCreated":"1574187658","dateModified":"1574187658"},{"type":"update","diffId":"18243","author":"durin42","id":"109678","dateCreated":"1574187647","dateModified":"1574187647"},{"type":"inline","comment":"same here about missing `]`.","replyTo":null,"isNewFile":"1","line":"414","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18240","author":"dlax","id":"109674","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"inline","comment":"`]` is still at the wrong place, I think. Should be `Callable[[Union[bytes, str]], bytestr]`.\nThen I still get the \"Name 'bytestr' is not defined\" error mentioned above.","replyTo":null,"isNewFile":"1","line":"305","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18240","author":"dlax","id":"109673","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"comment","comment":"Sorry, still not ok afaict :\/","author":"dlax","id":"109672","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"reject","author":"dlax","id":"109671","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"update","diffId":"18240","author":"durin42","id":"109659","dateCreated":"1574180082","dateModified":"1574180082"},{"type":"comment","comment":"@durin42 I just queued most of the remaining patches in this series. This one still needs your attention, it appears.","author":"indygreg","id":"109571","dateCreated":"1574135272","dateModified":"1574135272"},{"type":"inline","comment":"A `]` is missing before `, bytestr`. Then, it's also missing `typing` imports.\nBut, even with this, I get:\n\n```\nInvalid type comment: Callable[[Union[bytes, str]], bytestr] [invalid-type-comment]\n  Name 'bytestr' is not defined\n```\n\nI'm able to make this pass with:\n```\nbytestr = _bytestr\nbytestr = bytestr  # type: Callable[[Union[bytes, str]], bytestr]\n```\n\n","replyTo":null,"isNewFile":"1","line":"294","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18170","author":"dlax","id":"109308","dateCreated":"1573896532","dateModified":"1573896532"},{"type":"reject","author":"dlax","id":"109307","dateCreated":"1573896532","dateModified":"1573896532"},{"type":"update","diffId":"18170","author":"durin42","id":"109260","dateCreated":"1573854911","dateModified":"1573854911"},{"type":"comment","comment":"black complains because inline comments have only one space before (esp. the first one produces a parse error).\nLGTM otherwise.","author":"dlax","id":"109206","dateCreated":"1573840061","dateModified":"1573840061"},{"type":"update","diffId":"18163","author":"durin42","id":"109203","dateCreated":"1573839171","dateModified":"1573839171"},{"type":"update","diffId":"18161","author":"durin42","id":"109198","dateCreated":"1573839068","dateModified":"1573839068"},{"type":"comment","comment":"Rather `class bytestr(bytes):  # type: Callable[[Union[bytes, str], bytestr]` as @yuya suggested in D7380.","author":"dlax","id":"109159","dateCreated":"1573815818","dateModified":"1573815818"},{"type":"reject","author":"dlax","id":"109157","dateCreated":"1573815818","dateModified":"1573815818"},{"type":"comment","comment":"```\nclass bytestr(bytes):  # type: (Union[bytes,str]) -> bytestr\n  [...]\n```\n\nDoes this work?","author":"dlax","id":"108595","dateCreated":"1573729523","dateModified":"1573729523"},{"type":"update","diffId":"18066","author":"durin42","id":"108497","dateCreated":"1573703466","dateModified":"1573703466"},{"type":"comment","comment":"I'm going to mark for revisions until we know more so this doesn't show up in the reviewable list.","author":"indygreg","id":"107463","dateCreated":"1573231683","dateModified":"1573231683"},{"type":"reject","author":"indygreg","id":"107462","dateCreated":"1573231683","dateModified":"1573231683"},{"type":"comment","comment":"I've filed a bug with the pytype team, I'll report back.","author":"durin42","id":"106946","dateCreated":"1573142864","dateModified":"1573142864"},{"type":"comment","comment":"This one makes me sad because of potential performance regressions due to call overhead. I'd almost rather rip out Python 2 support rather than land this. But I could be convinced if pytypes is as cool as you say...\n\nIs there no way to annotate the types here without the call overhead? Could we do something like an `if False` trick to define a `def bytestr()` with the proper annotations? Surely there's got to be a way...","author":"indygreg","id":"106892","dateCreated":"1573115914","dateModified":"1573115914"},{"type":"update","diffId":"17672","author":"durin42","id":"106678","dateCreated":"1573082663","dateModified":"1573082663"}],"dateCreated":"1573082663","dateModified":"1584719973","status":"Changes Planned"},{"id":"7967","callsign":"HG","title":"exchange: recognize changegroup3 bundles in `getbundlespec()`","author":"mharbison72","summary":"Previously, `hg bundle --spec $bundle` complained that changegroup3 didn't have\na known bundlespec and suggested upgrading the client, even if the same binary\ngenerated the bundle.","testPlan":"","lineCount":"28","dependsOn":[],"reviewers":["marmoute"],"ccs":["indygreg","marmoute","pulkit","joerg.sonnenberger","mercurial-devel"],"actions":[{"type":"comment","comment":"It looks like futher change will be necessary on this patch, moving it out of yadaa","author":"marmoute","id":"124082","dateCreated":"1584668017","dateModified":"1584668017"},{"type":"reject","author":"marmoute","id":"124081","dateCreated":"1584668017","dateModified":"1584668017"},{"type":"inline","comment":"> That being said, for purposes of parsing a bundle, it _might_ be acceptable to allow experimental\n> features through. We absolutely cannot do that on the write side, however, as it completely breaks\n> the bundle spec contract that content is well-defined.\n\nThat's concerning (I think).\n\nI got onto this path trying to generate clonebundles for a repo that uses LFS.  LFS forces the experimental changegroup3 (and removes the others as options).  I was able to generate the bundle, and was using this to try to figure out what the magic string was for filling out the manifest.  So there are bundles of a not-reported spec in the wild (I assume this is what you meant by the write side).  And if we were to BC changegroup3 for example, IDK how we tell that these older bundles are *not* whatever the new bundlespec becomes, since it seems that the only additional needed logic is to look for changegroup3.\n","replyTo":"121577","isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/exchange.py","diffId":"19502","author":"mharbison72","id":"121579","dateCreated":"1582777785","dateModified":"1582777785"},{"type":"inline","comment":"Since changegroup `v3` is not advertised in an existing bundle spec definition at the top of this file, the proper thing to do here is create a new `v3` bundle specification that uses changegroup v3 by default. Then all bundle spec `v3` will be compatible with changegroup `v3`.\n\nBut before we create a new bundle spec, all features within it need to be non-experimental. The whole point of bundle specs is that if 2 clients of different versions claim they support a bundle spec, they actually do. If the content of a bundle change within a bundle spec, that's a BC.\n\nIf changegroup `v3` isn't stable yet, we should not be associating it with a bundle spec because a claimed `v2` bundle spec may not be readable by an old version or a client without the experimental feature enabled. That breaks the contract of bundle specifications.\n\nThat being said, for purposes of parsing a bundle, it _might_ be acceptable to allow experimental features through. We absolutely cannot do that on the write side, however, as it completely breaks the bundle spec contract that content is well-defined.","replyTo":"117057","isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/exchange.py","diffId":"19502","author":"indygreg","id":"121577","dateCreated":"1582760232","dateModified":"1582760232"},{"type":"comment","comment":"To clarify, bundle specifications are user-facing whereas changegroup versions are an internal implementation detail. Their version numbers are thus on different timelines and aren't strictly related.\n\nA bundle specification version is essentially a collection of related bundle features at a given point in time. One of those bundle features would be the changegroup version. The idea is that every time we add a significant feature to bundles and want to expose that feature to users, we would bake a new bundle specification version that encapsulates that change. Over time, I would expect the total number of bundle specification versions to outnumber the changegroup versions, as any BC change to a bundle would incur a new bundle specification and there are more changes to bundles than just the changegroup format.\n\nWhile I'm here, in the context of bundle2, a monolithic changegroup bundle part doesn't make as much sense any more. We should arguably do away with the monolithic changegroup bundle2 part and instead send a series of deltas to named paths. But that's way beyond the scope of this review :)","author":"indygreg","id":"121576","dateCreated":"1582759818","dateModified":"1582759818"},{"type":"comment","comment":"It seems like I faild to have a look soon\u2122","author":"marmoute","id":"121561","dateCreated":"1582746860","dateModified":"1582746860"},{"type":"comment","comment":">>! In D7967#118158, @marmoute wrote:\n> I can confirm the spec version number are different to the changegroup version number. For the rest. I'll try to have a look soon.\n\nGentle ping on this","author":"mharbison72","id":"121559","dateCreated":"1582746790","dateModified":"1582746790"},{"type":"comment","comment":"I can confirm the spec version number are different to the changegroup version number. For the rest. I'll try to have a look soon.","author":"marmoute","id":"118158","dateCreated":"1580119112","dateModified":"1580119112"},{"type":"inline","comment":"I\u2019m not sure now. I think I went this way because I\u2019m pretty sure it complained when I tried to generate a bzip2-v3 bundle.  And since 01 is mapped to v2 and the error message is talking about finding a bundlespec, it seemed like v2 was the only option.  But maybe something is missing elsewhere too.  @marmoute?","replyTo":"117054","isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/exchange.py","diffId":"19502","author":"mharbison72","id":"117057","dateCreated":"1579698258","dateModified":"1579698258"},{"type":"inline","comment":"Should not this be `v3`? I believe this is what @joerg.sonnenberger is also trying to point out on IRC.","replyTo":null,"isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/exchange.py","diffId":"19502","author":"pulkit","id":"117054","dateCreated":"1579697239","dateModified":"1579697239"},{"type":"update","diffId":"19502","author":"mharbison72","id":"117047","dateCreated":"1579649502","dateModified":"1579649502"}],"dateCreated":"1579649502","dateModified":"1584668017","status":"Needs Revision"},{"id":"8290","callsign":"HG","title":"morestatus: recommend `hg resolve --clear` when appropriate","author":"martinvonz","summary":"","testPlan":"","lineCount":"5","dependsOn":["8289"],"reviewers":["marmoute"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"This on seems need to be updated with `hg update --continue\/hg continue`","author":"marmoute","id":"124073","dateCreated":"1584662533","dateModified":"1584662533"},{"type":"reject","author":"marmoute","id":"124072","dateCreated":"1584662533","dateModified":"1584662533"},{"type":"update","diffId":"20779","author":"martinvonz","id":"123736","dateCreated":"1584134456","dateModified":"1584134456"}],"dateCreated":"1584134456","dateModified":"1584662533","status":"Needs Revision"},{"id":"8289","callsign":"HG","title":"resolve: add a --clear option for clearing the merge state","author":"martinvonz","summary":"E.g. after running `hg co -m` and resolving merge conflicts, the merge\nstate will still exist. That can be seen when running `hg resolve -l`\nor `hg status -v` (a.k.a.  morestatus). There's currently no good way\nof clearing it (`hg co -C .` works, but is not an option if you have a\ndirty working copy). This patch adds `hg resolve --clear` specifically\nfor clearing the merge state.","testPlan":"","lineCount":"57","dependsOn":[],"reviewers":[],"ccs":["marmoute","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D8289#124060, @marmoute wrote:\n>>>! In D8289#124009, @pulkit wrote:\n>> 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.\n>> \n>> Maybe we should not let user clear the mergestate and suggest `continue\/<cmd-name> --continue` if it's not result of update command. Thoughts?\n> \n> 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 ?\n\nYeah, I agree (sorry, was busy with other stuff today). It should be easy to change this patch from `hg resolve --clear` to `hg update --continue`. I might add the `hg continue` support as separate patch on top.","author":"martinvonz","id":"124062","dateCreated":"1584662143","dateModified":"1584662143"},{"type":"plan-changes","author":"martinvonz","id":"124061","dateCreated":"1584662143","dateModified":"1584662143"},{"type":"comment","comment":">>! In D8289#124009, @pulkit wrote:\n> 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.\n> \n> Maybe we should not let user clear the mergestate and suggest `continue\/<cmd-name> --continue` if it's not result of update command. Thoughts?\n\nHo, 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 ?","author":"marmoute","id":"124060","dateCreated":"1584661388","dateModified":"1584661388"},{"type":"comment","comment":"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.\n\nMaybe we should not let user clear the mergestate and suggest `continue\/<cmd-name> --continue` if it's not result of update command. Thoughts?","author":"pulkit","id":"124009","dateCreated":"1584606645","dateModified":"1584606645"},{"type":"update","diffId":"20820","author":"martinvonz","id":"123959","dateCreated":"1584482717","dateModified":"1584482717"},{"type":"update","diffId":"20778","author":"martinvonz","id":"123731","dateCreated":"1584134455","dateModified":"1584134455"}],"dateCreated":"1584134455","dateModified":"1584662143","status":"Changes Planned"},{"id":"7574","callsign":"HG","title":"hg-core: add utils::path to project","author":"indygreg","summary":"This module was vendored in the previous commit but was not integrated into\nthe project. This commit performs that integration.\n\nAs part of this, we have to add a handful of new dependencies. The new\ndependencies all seem quite reasonable. The versions taken were the exact\nones used by the upstream project.","testPlan":"","lineCount":"309","dependsOn":[],"reviewers":["pulkit","marmoute"],"ccs":["marmoute","Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"Looks like there are unresolved discussion about error handling here.","author":"marmoute","id":"124048","dateCreated":"1584659079","dateModified":"1584659079"},{"type":"reject","author":"marmoute","id":"124047","dateCreated":"1584659079","dateModified":"1584659079"},{"type":"comment","comment":"This one fails to apply with conflicts in `Cargo.lock`.","author":"pulkit","id":"115314","dateCreated":"1578933699","dateModified":"1578933699"},{"type":"reject","author":"pulkit","id":"115313","dateCreated":"1578933699","dateModified":"1578933699"},{"type":"accept","author":"pulkit","id":"115309","dateCreated":"1578933323","dateModified":"1578933323"},{"type":"inline","comment":"I actually wasn't aware of `anyhow` before writing this patch. And I have to say that I really like `anyhow` because it is simpler than other crates in this space while offering much of the same functionality.\n\nI think it is inevitable that we'll want to use a crate like `anyhow` for more advanced error handling. If nothing else, it can help cut down on boilerplate code around error handling.","replyTo":"111442","isNewFile":"1","line":"12","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18534","author":"indygreg","id":"113657","dateCreated":"1577124884","dateModified":"1577124884"},{"type":"inline","comment":"Should we adopt this crate for error handling?\n\nI feel like our current solution - although it might need a refactor - is good at forcing the programmer to provide context with finer-grained errors that what you are required to do with `anyhow`.  I actually like `anyhow` better than more involved crates, but we will need to have a good \"error hygiene\" if you will.\n\nThis seems like a better place to discuss this than the previous patch.","replyTo":null,"isNewFile":"1","line":"12","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18534","author":"Alphare","id":"111442","dateCreated":"1575888850","dateModified":"1575888850"},{"type":"update","diffId":"18534","author":"indygreg","id":"111325","dateCreated":"1575749869","dateModified":"1575749869"}],"dateCreated":"1575749869","dateModified":"1584659079","status":"Needs Revision"},{"id":"8227","callsign":"HG","title":"hgit: use type_str instead of type for checking type of git objects","author":"pulkit","summary":"type returns a constant which were integers.\n\nhttps:\/\/www.pygit2.org\/objects.html#pygit2.Object.type","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"I should add some tests.","author":"pulkit","id":"122409","dateCreated":"1583420586","dateModified":"1583420586"},{"type":"plan-changes","author":"pulkit","id":"122408","dateCreated":"1583420586","dateModified":"1583420586"},{"type":"update","diffId":"20506","author":"pulkit","id":"122405","dateCreated":"1583419454","dateModified":"1583419454"},{"type":"update","diffId":"20505","author":"pulkit","id":"122400","dateCreated":"1583419181","dateModified":"1583419181"}],"dateCreated":"1583419181","dateModified":"1583420586","status":"Changes Planned"},{"id":"7257","callsign":"HG","title":"[RFC] repoview: add a \"filter\" that just disallows walking to heads","author":"martinvonz","summary":"This can let us find bugs where we think it shouldn't matter whether\nwe're using an unfiltered or filtered repo. We could then get a repo\nthat is using this new \"filter\" and if the code ends up trying to walk\nthe graph towards the changelog children, we would notice that.","testPlan":"","lineCount":"30","dependsOn":[],"reviewers":["durin42","baymax"],"ccs":["durin42","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"121134","dateCreated":"1582275051","dateModified":"1582275051"},{"type":"reject","author":"baymax","id":"121133","dateCreated":"1582275051","dateModified":"1582275051"},{"type":"comment","comment":"I'm a big fan of this idea. I'd probably land it if there were some obvious usecases as child patches. :)","author":"durin42","id":"108443","dateCreated":"1573686616","dateModified":"1573686616"},{"type":"accept","author":"durin42","id":"108442","dateCreated":"1573686616","dateModified":"1573686616"},{"type":"comment","comment":">>! In D7257#108377, @marmoute wrote:\n> Can you elaborate on what this changeset is about ? the description is a bit\u2026 short;-)\n\nDone.","author":"martinvonz","id":"108379","dateCreated":"1573597314","dateModified":"1573597314"},{"type":"comment","comment":"Can you elaborate on what this changeset is about ? the description is a bit\u2026 short;-)","author":"marmoute","id":"108377","dateCreated":"1573596371","dateModified":"1573596371"},{"type":"update","diffId":"18048","author":"martinvonz","id":"108373","dateCreated":"1573594402","dateModified":"1573594402"},{"type":"update","diffId":"17625","author":"martinvonz","id":"106360","dateCreated":"1573059703","dateModified":"1573059703"}],"dateCreated":"1573059703","dateModified":"1582275051","status":"Needs Revision"},{"id":"7728","callsign":"HG","title":"rebase: add test to demonstrate issue6180","author":"khanchi97","summary":"It will be fixed in next patch.","testPlan":"","lineCount":"63","dependsOn":[],"reviewers":["marmoute"],"ccs":["marmoute","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"As per comment of Pulkit and I on D7730, please spin this test toward forbiding the prune while the rebase is in progress.","author":"marmoute","id":"120855","dateCreated":"1581669482","dateModified":"1581669482"},{"type":"reject","author":"marmoute","id":"120854","dateCreated":"1581669482","dateModified":"1581669482"},{"type":"comment","comment":"Cf my comment on D7730, I think the bug is more about letting others commands obsoleting things happens (eg, amend, pull, etc) than rebase being confused by the result.","author":"marmoute","id":"119015","dateCreated":"1580600761","dateModified":"1580600761"},{"type":"update","diffId":"19815","author":"khanchi97","id":"119011","dateCreated":"1580582406","dateModified":"1580582406"},{"type":"update","diffId":"19282","author":"khanchi97","id":"115765","dateCreated":"1579084940","dateModified":"1579084940"},{"type":"inline","comment":"You don't need to redefine it.","replyTo":null,"isNewFile":"1","line":"438","lineLength":"0","path":"tests\/test-rebase-conflicts.t","diffId":"18937","author":"pulkit","id":"114951","dateCreated":"1578579588","dateModified":"1578579588"},{"type":"comment","comment":"Ping.","author":"khanchi97","id":"114662","dateCreated":"1578483193","dateModified":"1578483193"},{"type":"update","diffId":"18937","author":"khanchi97","id":"113781","dateCreated":"1577465814","dateModified":"1577465814"}],"dateCreated":"1577465814","dateModified":"1581669482","status":"Needs Revision"},{"id":"7730","callsign":"HG","title":"rebase: make sure pruning does not confuse rebase (issue6180)","author":"khanchi97","summary":"Before this patch, if a user is rebasing a stack of commits and\nhit a conflict in between and decided to drop that commit (the commit\nwhich is being rebased but hit conflict) and pruned it, now what\n`hg rebase --continue` does is: skip that dropped commit and move\non to rebase the next commit and gets confused here because wdir\nhas two parents which is because while we skipped that dropped\ncommit wdir had two parents and we didn't update that to one parent.\n\nChanges in test file demonstrate the fixed behavior.","testPlan":"","lineCount":"11","dependsOn":["7728"],"reviewers":["martinvonz","marmoute"],"ccs":["marmoute","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7730#119191, @pulkit wrote:\n>>>! In D7730#117268, @marmoute wrote:\n>> I think is would be simpler and sfare to prevent unrelated operation during rebase. If the user cannot prune here we won't have to deal with it. This woudl also apply to other operation that can alter the repository, like another rebase, amend or a pull. Starting using a unified and safe approach seems to provide more benefit with less chance of UI inconsistency.\n> \n> I agree. We should disallow prune if an unfinished operation exists.\n\nOkay, lets to in this direction then.","author":"marmoute","id":"120852","dateCreated":"1581668628","dateModified":"1581668628"},{"type":"reject","author":"marmoute","id":"120851","dateCreated":"1581668628","dateModified":"1581668628"},{"type":"comment","comment":">>! In D7730#117268, @marmoute wrote:\n> I think is would be simpler and sfare to prevent unrelated operation during rebase. If the user cannot prune here we won't have to deal with it. This woudl also apply to other operation that can alter the repository, like another rebase, amend or a pull. Starting using a unified and safe approach seems to provide more benefit with less chance of UI inconsistency.\n\nI agree. We should disallow prune if an unfinished operation exists.","author":"pulkit","id":"119191","dateCreated":"1580815575","dateModified":"1580815575"},{"type":"update","diffId":"19816","author":"khanchi97","id":"119012","dateCreated":"1580582417","dateModified":"1580582417"},{"type":"comment","comment":"I think is would be simpler and sfare to prevent unrelated operation during rebase. If the user cannot prune here we won't have to deal with it. This woudl also apply to other operation that can alter the repository, like another rebase, amend or a pull. Starting using a unified and safe approach seems to provide more benefit with less chance of UI inconsistency.","author":"marmoute","id":"117268","dateCreated":"1579797320","dateModified":"1579797320"},{"type":"inline","comment":"Actually, doesn't this need to be `wctx.setparents()` (which you can do now that D7822 has been queued) in order to work with in-memory rebase? Maybe time to add a test case with in-memory rebase?","replyTo":null,"isNewFile":"1","line":"600","lineLength":"0","path":"hgext\/rebase.py","diffId":"19283","author":"martinvonz","id":"115947","dateCreated":"1579106322","dateModified":"1579106322"},{"type":"inline","comment":"No need, I've already sent D7827","replyTo":"115783","isNewFile":"1","line":"597","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"martinvonz","id":"115944","dateCreated":"1579106125","dateModified":"1579106125"},{"type":"inline","comment":"I will look into it.","replyTo":"114713","isNewFile":"1","line":"597","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"khanchi97","id":"115783","dateCreated":"1579093511","dateModified":"1579093511"},{"type":"comment","comment":">>! In D7730#114953, @pulkit wrote:\n> Unrelated to the fix, we need better way to skip commits during rebasing. Pruning manually is not a good option, IIRC git rebase have a `--skip` flag.\n\nYeah, that's a good idea. We should also have --skip flag to skip the commit on which rebase got interrupted.","author":"khanchi97","id":"115781","dateCreated":"1579093387","dateModified":"1579093387"},{"type":"update","diffId":"19283","author":"khanchi97","id":"115766","dateCreated":"1579084952","dateModified":"1579084952"},{"type":"comment","comment":"Unrelated to the fix, we need better way to skip commits during rebasing. Pruning manually is not a good option, IIRC git rebase have a `--skip` flag.","author":"pulkit","id":"114953","dateCreated":"1578579692","dateModified":"1578579692"},{"type":"inline","comment":"I think it's incorrect that rebase sets two parents while the merge is being resolved, but that's out of scope for this patch.","replyTo":null,"isNewFile":"1","line":"597","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"martinvonz","id":"114713","dateCreated":"1578505063","dateModified":"1578505063"},{"type":"inline","comment":"Should this be `self.wctx.parents()` to work with in-memory rebase?","replyTo":null,"isNewFile":"1","line":"598","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"martinvonz","id":"114712","dateCreated":"1578505063","dateModified":"1578505063"},{"type":"comment","comment":"Ping.","author":"khanchi97","id":"114663","dateCreated":"1578483218","dateModified":"1578483218"},{"type":"update","diffId":"18939","author":"khanchi97","id":"113800","dateCreated":"1577466343","dateModified":"1577466343"}],"dateCreated":"1577466343","dateModified":"1581668628","status":"Needs Revision"},{"id":"7942","callsign":"HG","title":"py3: make test-http-bad-server.t conditional on Python 3.6+","author":"indygreg","summary":"I'm not sure what's going on here, but we need to limit these lines\nto a Python 3.6 version range check because Python 3.5's behavior\nis subtly different. We already had some lines conditional on\nPython 3.5+ and 3.6+. I guess whoever made this test pass on 3.6+\nforgot to test on 3.5+.\n\nWith this change, the test harness is clean on Python 3.5 on Linux\non my machine.","testPlan":"","lineCount":"10","dependsOn":["7941"],"reviewers":["pulkit","marmoute"],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"accept","author":"marmoute","id":"119441","dateCreated":"1580944098","dateModified":"1580944098"},{"type":"accept","author":"pulkit","id":"116764","dateCreated":"1579528946","dateModified":"1579528946"},{"type":"update","diffId":"19446","author":"indygreg","id":"116676","dateCreated":"1579333363","dateModified":"1579333363"}],"dateCreated":"1579333363","dateModified":"1580944098","status":"Accepted"},{"id":"7940","callsign":"HG","title":"py3: make flush() line optional","author":"indygreg","summary":"This line only appears on Python 3.5, not on 2.7 or 3.6+. Why, I have\nno clue. I suspect a weird regression in the bowels of Python's\nI\/O system.\n\nOur test format doesn't support combining conditionals. So I add\npyexactXY checks to check for an exact major.minor Python version.\nSadly, this won't be the only test requiring an exception for\nPython 3.5.","testPlan":"","lineCount":"12","dependsOn":[],"reviewers":["pulkit","marmoute"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"inline","comment":"\n+1 are we missing anything that prevent this to be used?","replyTo":"116766","isNewFile":"1","line":"114","lineLength":"0","path":"tests\/test-ssh-proto.t","diffId":"19444","author":"marmoute","id":"119439","dateCreated":"1580943965","dateModified":"1580943965"},{"type":"inline","comment":"can we pre-generate more python version ? It help running \"current\" extension test againts \"older\" mercurial version.","replyTo":null,"isNewFile":"1","line":"783","lineLength":"0","path":"tests\/hghave.py","diffId":"19444","author":"marmoute","id":"119438","dateCreated":"1580943965","dateModified":"1580943965"},{"type":"reject","author":"marmoute","id":"119437","dateCreated":"1580943965","dateModified":"1580943965"},{"type":"inline","comment":"Reviewing later patches, I see that `(py3 no-py3.6)` can be used for this.","replyTo":null,"isNewFile":"1","line":"114","lineLength":"0","path":"tests\/test-ssh-proto.t","diffId":"19444","author":"pulkit","id":"116766","dateCreated":"1579529000","dateModified":"1579529000"},{"type":"accept","author":"pulkit","id":"116758","dateCreated":"1579528720","dateModified":"1579528720"},{"type":"update","diffId":"19444","author":"indygreg","id":"116660","dateCreated":"1579333360","dateModified":"1579333360"}],"dateCreated":"1579333360","dateModified":"1580943966","status":"Needs Revision"},{"id":"7176","callsign":"HG","title":"rebase: allow rebasing obsolete commit without successor","author":"martinvonz","summary":"When trying to rebase an obsolete whose successors are also all\nobsolete, we would skip it and tell the user that it would have caused\ndivergence. That is not correct. We could just change the message, but\nI don't see any harm in rebasing such commits. It even seems like a\nreasonable way to make it not obsolete. So this patch makes that type\nof rebase allowed.","testPlan":"","lineCount":"9","dependsOn":["7175"],"reviewers":["baymax"],"ccs":["marmoute","khanchi97","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"118730","dateCreated":"1580407580","dateModified":"1580407580"},{"type":"reject","author":"baymax","id":"118729","dateCreated":"1580407580","dateModified":"1580407580"},{"type":"comment","comment":"That is not necessarly True, If the changeset is pruned, but successors of a public changeset, rebasing it would create phase-divergence. @khanchi97 fixed similar cases in September.\n\nOverall, we should migrate the rebase code to use the `precheck` logic in rewrite util (and make sure things are well covered there).\n\nOne can read more about current Sushil work in this area here: https:\/\/www.mercurial-scm.org\/wiki\/CEDPrecheckPlan.","author":"marmoute","id":"105351","dateCreated":"1572465579","dateModified":"1572465579"},{"type":"update","diffId":"17409","author":"martinvonz","id":"105299","dateCreated":"1572050933","dateModified":"1572050933"}],"dateCreated":"1572050933","dateModified":"1580407580","status":"Needs Revision"},{"id":"3896","callsign":"HG","title":"copies: handle case when both merge cset are not descendant of merge base","author":"pulkit","summary":"There can be cases when both the changesets which we are merging are not\ndescendants of the merge base. In those cases dirtyc1 and dirtyc2 both will be\ntrue. The existing code assumes that either of them will be true always but that\nis not a right assumption.\n\nI found this while working with content-divergence resolution. In\ncontent-divergence resolution, we use the common predecessor as the merge base\nfor resolving content divergence and there it can be possible that the merge\nbase is not the descendant of both the content-divergence changsets.\n\nThe code in content-divergence which does this is at:\nhttps:\/\/www.mercurial-scm.org\/repo\/evolve\/file\/b81fd1487e04\/hgext3rd\/evolve\/evolvecmd.py#l507","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":["baymax"],"ccs":["martinvonz","spectral","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Pretty sure this was made obsolete by D6255","author":"martinvonz","id":"118457","dateCreated":"1580315479","dateModified":"1580315479"},{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117663","dateCreated":"1579887172","dateModified":"1579887172"},{"type":"reject","author":"baymax","id":"117662","dateCreated":"1579887172","dateModified":"1579887172"},{"type":"comment","comment":">>! In D3896#65986, @spectral wrote:\n> Any updates on this?  I'm poking at updating this function in core, and not too excited to have to also modify the copy in evolve that seems to have spawned :\/\n\nI am yet to write tests. Feel free to update the one in core, I will take care of the evolve copy.","author":"pulkit","id":"66180","dateCreated":"1534428512","dateModified":"1534428512"},{"type":"comment","comment":"Any updates on this?  I'm poking at updating this function in core, and not too excited to have to also modify the copy in evolve that seems to have spawned :\/","author":"spectral","id":"65987","dateCreated":"1534370496","dateModified":"1534370496"},{"type":"comment","comment":"Can you add some tests that make both `dirtyc1` and `dirtyc2` set, and\ntrigger copy tracing?\n\n> Since we can have both dirtyc1, and dirtyc2 true, I am not sure whether\n> this else should be turned into it's own if statement?\n\nNo idea. I doubt if the current copy tracing can handle such cases. From\nmy vague memory, the current algorithm relies on the fact that the pseudo\n`base` revision exists in between the `c1` and the `c2`.","author":"yuja","id":"60811","dateCreated":"1531138991","dateModified":"1531138991"},{"type":"inline","comment":"Since we can have both dirtyc1, and dirtyc2 true, I am not sure whether this else should be turned into it's own if statement?","replyTo":null,"isNewFile":"1","line":"496","lineLength":"0","path":"mercurial\/copies.py","diffId":"9471","author":"pulkit","id":"60802","dateCreated":"1531041256","dateModified":"1531041256"},{"type":"update","diffId":"9471","author":"pulkit","id":"60797","dateCreated":"1531041116","dateModified":"1531041116"}],"dateCreated":"1531041116","dateModified":"1580315479","status":"Needs Revision"},{"id":"1700","callsign":"HG","title":"logtoprocess: pass ui in runshellcommand","author":"lothiraldan","summary":"We are gonna read a configuration specific to Windows, instead of adding a\nuseless arguments for runshellcommand on linux, pass the ui object to read it\ndirectly.","testPlan":"","lineCount":"6","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117739","dateCreated":"1579887208","dateModified":"1579887208"},{"type":"reject","author":"baymax","id":"117738","dateCreated":"1579887208","dateModified":"1579887208"},{"type":"update","diffId":"4467","author":"lothiraldan","id":"29023","dateCreated":"1513332655","dateModified":"1513332655"}],"dateCreated":"1513332655","dateModified":"1579887208","status":"Needs Revision"},{"id":"1752","callsign":"HG","title":"tests: show phases aren't preserved part of streaming clone (issue5648)","author":"indygreg","summary":"draft and secret changesets are promoted to public changesets when\ntransferred via a stream clone. That's not desirable behavior. Add\ntests demonstrating it.\n\nAs far as I can tell, this buggy behavior has been present since\nphases were introduced. Stream clone predated phases (1.7 versus 1.9)\nand stream clone was never taught to be phase aware.","testPlan":"","lineCount":"65","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117733","dateCreated":"1579887204","dateModified":"1579887204"},{"type":"reject","author":"baymax","id":"117732","dateCreated":"1579887204","dateModified":"1579887204"},{"type":"update","diffId":"4602","author":"indygreg","id":"29880","dateCreated":"1514138808","dateModified":"1514138808"}],"dateCreated":"1514138808","dateModified":"1579887205","status":"Needs Revision"},{"id":"1765","callsign":"HG","title":"parsers: use an attr-derived class for revlog index entries","author":"indygreg","summary":"Currently, revlog index entries are tuples.\n\nThis commit introduces a new type to represent revlog v1 index\nentries. The pure Python parser has been converted to use it.\n\nTo provide backwards compatibility with existing code (including the\nC extension), the type has a __getitem__ to facilitate index\nlookups. The intent is to remove this __getitem__ once all consumers\nare using named attributes.\n\nSince the pure Python index parser is now using our new type,\ntest-parseindex2.py had to be updated to deal with the type mismatch.\nOnce all index parsers are converted and the new type\/interface is\nubiquitous, we can restore the simplicity of test-parseindex2.py. We\nalso had to (temporarily) add \"# no-check-code\" to test-parseindex2.py\nto allow the import of the pure module. This will be removed once the C\nextension is ported.\n\nBecause consumers are going through an extra Python function call to\n__getitem__ to resolve attributes by index, this change regresses\nperformance on a simple DAG walking revset for the Firefox repository:\n\n$ HGMODULEPOLICY=py hg perfrevset '::tip'\n! wall 1.366281 comb 1.360000 user 1.360000 sys 0.000000 (best of 7)\n! wall 1.860068 comb 1.860000 user 1.860000 sys 0.000000 (best of 5)\n\nUsing PyPy, a major regression is not apparent:\n\n! wall 0.163141 comb 0.160000 user 0.160000 sys 0.000000 (best of 56)\n! wall 0.154325 comb 0.160000 user 0.160000 sys 0.000000 (best of 54)","testPlan":"","lineCount":"70","dependsOn":[],"reviewers":["yuja","durin42","baymax"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117730","dateCreated":"1579887202","dateModified":"1579887202"},{"type":"reject","author":"baymax","id":"117729","dateCreated":"1579887202","dateModified":"1579887202"},{"type":"accept","author":"durin42","id":"31062","dateCreated":"1515624886","dateModified":"1515624886"},{"type":"update","diffId":"4735","author":"indygreg","id":"30856","dateCreated":"1515227175","dateModified":"1515227175"},{"type":"inline","comment":"Perhaps you mean `list(map(...))` instead of a list of one element?","replyTo":null,"isNewFile":"1","line":"182","lineLength":"0","path":"tests\/test-parseindex2.py","diffId":"4626","author":"yuja","id":"30602","dateCreated":"1515124211","dateModified":"1515124211"},{"type":"reject","author":"yuja","id":"30601","dateCreated":"1515124211","dateModified":"1515124211"},{"type":"update","diffId":"4626","author":"indygreg","id":"30049","dateCreated":"1514334949","dateModified":"1514334949"}],"dateCreated":"1514334949","dateModified":"1579887202","status":"Needs Revision"},{"id":"1767","callsign":"HG","title":"cext: make nullentry a member of index types","author":"indygreg","summary":"An upcoming commit will change the type of index entries from tuple\nto something else. This type may not be initialized\/available at\nmodule init time.\n\nWe prepare for this future change by making null entries a per-instance\nvariable on the index type.\n\nIn theory, this does add some overhead (a new 8-tuple per index\ninstance). However, the overhead should be negligible compared to\nthe run-time overhead of creating an index entry for each revision\nin the index.","testPlan":"","lineCount":"19","dependsOn":["1766"],"reviewers":["yuja","durin42","baymax"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117727","dateCreated":"1579887200","dateModified":"1579887200"},{"type":"reject","author":"baymax","id":"117726","dateCreated":"1579887200","dateModified":"1579887200"},{"type":"accept","author":"durin42","id":"31065","dateCreated":"1515624888","dateModified":"1515624888"},{"type":"update","diffId":"4736","author":"indygreg","id":"30859","dateCreated":"1515227176","dateModified":"1515227176"},{"type":"inline","comment":"This comment shouldn't be moved. We need to NULLify all attributes, but don't\nhave to create PyObject.","replyTo":null,"isNewFile":"1","line":"1876","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4628","author":"yuja","id":"30606","dateCreated":"1515124415","dateModified":"1515124415"},{"type":"reject","author":"yuja","id":"30605","dateCreated":"1515124415","dateModified":"1515124415"},{"type":"update","diffId":"4628","author":"indygreg","id":"30069","dateCreated":"1514334953","dateModified":"1514334953"}],"dateCreated":"1514334953","dateModified":"1579887200","status":"Needs Revision"},{"id":"1768","callsign":"HG","title":"cext: obtain reference to index entry type","author":"indygreg","summary":"We recently introduced a dedicated type for index entries in the\npure Python implementation.\n\nThis commit tells the revlog C code about that type.\n\nWe register the type on the parsers module so it is exposed to\nimporters of the module.\n\nIn addition, we store a reference to the type on revlog index\ninstances. In theory, we could grab the reference from the\nmodule. However, this requires a fair bit of C code. It is easier\nto just re-import the original module and get a ref from there. This\nalso avoids problems with caching a type on a reload()d module.","testPlan":"","lineCount":"35","dependsOn":["1767"],"reviewers":["yuja","durin42","baymax"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117724","dateCreated":"1579887199","dateModified":"1579887199"},{"type":"reject","author":"baymax","id":"117723","dateCreated":"1579887199","dateModified":"1579887199"},{"type":"accept","author":"durin42","id":"31066","dateCreated":"1515624888","dateModified":"1515624888"},{"type":"update","diffId":"4737","author":"indygreg","id":"30861","dateCreated":"1515227177","dateModified":"1515227177"},{"type":"inline","comment":"In theory, there could be a mismatch.\n\nIf this module is loaded, its `IndexV1Entry` will refer to whatever `mercurial.pure.parsers.IndexV1Entry` is. If `mercurial.pure.parsers` is then reloaded and its `IndexV1Entry` changes and a revlog index type is created, its `IndexV1Entry` will be the new one from the reloaded `mercurial.pure.parsers`.\n\nSince I plan to replace the Python-implemented type with a C backed type, I'm inclined to not care about this.","replyTo":"30611","isNewFile":"1","line":"2117","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4629","author":"indygreg","id":"30845","dateCreated":"1515222660","dateModified":"1515222660"},{"type":"inline","comment":"Can we be sure that this `IndexV1Entry` is identical to `self->entrytype`\nafter reloading Python modules?","replyTo":null,"isNewFile":"1","line":"2117","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4629","author":"yuja","id":"30611","dateCreated":"1515128067","dateModified":"1515128067"},{"type":"comment","comment":"> We hold off incrementing the version of the \"parsers\" extension\n> because nothing in core relies on the new API yet.\n\nIt's really minor nit, but we have to increment the version since new\ncompiled module doesn't work with old `pure.parsers` module, which\nprovides no IndexV1Entry type.","author":"yuja","id":"30610","dateCreated":"1515128067","dateModified":"1515128067"},{"type":"reject","author":"yuja","id":"30609","dateCreated":"1515128067","dateModified":"1515128067"},{"type":"update","diffId":"4629","author":"indygreg","id":"30079","dateCreated":"1514334955","dateModified":"1514334955"}],"dateCreated":"1514334955","dateModified":"1579887199","status":"Needs Revision"},{"id":"1769","callsign":"HG","title":"cext: use dedicated type for index entries","author":"indygreg","summary":"Now that we have a handle on our type to represent revlog index\nentries, let's use it.\n\nThis commit essentially consists of porting code from PyTuple to\nPyObject.\n\nAs part of porting the code, we now retrieve elements in the entry\ntype by named attribute instead of integer index.\n\nBefore, PyTuple_* APIs allowed us to retrieve a borrowed reference\nto PyObject elements. We can no longer do this via the PyObject_*\nAPIs for a type not implemented in C. This required extra refcount\nmanipulation in various places.\n\nThe C extension is now emitting the new type. And because various\ncode is still accessing index entry elements via __getitem__, we\nsee a performance regression in the Firefox repository:\n\n$ hg perfrevset '::tip'\n! wall 0.755869 comb 0.750000 user 0.750000 sys 0.000000 (best of 13)\n! wall 1.011107 comb 1.010000 user 1.010000 sys 0.000000 (best of 10)\n\nWe will claw back this regression in subsequent commits by accessing\nfields by name instead of index.\n\nThe version of the \"parsers\" C extension has been incremented to\nreflect the change in behavior.","testPlan":"","lineCount":"123","dependsOn":["1768"],"reviewers":["yuja","durin42","baymax"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117721","dateCreated":"1579887198","dateModified":"1579887198"},{"type":"reject","author":"baymax","id":"117720","dateCreated":"1579887198","dateModified":"1579887198"},{"type":"accept","author":"durin42","id":"31067","dateCreated":"1515624889","dateModified":"1515624889"},{"type":"update","diffId":"4738","author":"indygreg","id":"30864","dateCreated":"1515227178","dateModified":"1515227178"},{"type":"inline","comment":"No error reported to the caller.\n\nAttributeError would be set automatically.","replyTo":null,"isNewFile":"1","line":"1788","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30618","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"inline","comment":"I slightly prefer `goto bail` instead of `result = NULL; goto cleanup` pairs.","replyTo":null,"isNewFile":"1","line":"327","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30617","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"inline","comment":"This is tricky, but looks okay. Alternatively, we could inc\/decref borrowed `obj`.","replyTo":null,"isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30616","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"inline","comment":"Perhaps AttributeError would be set by `PyObject_GetAttrString()`.","replyTo":null,"isNewFile":"1","line":"141","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30615","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"reject","author":"yuja","id":"30614","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"update","diffId":"4630","author":"indygreg","id":"30089","dateCreated":"1514334957","dateModified":"1514334957"}],"dateCreated":"1514334957","dateModified":"1579887198","status":"Needs Revision"},{"id":"2158","callsign":"HG","title":"py3: use raw string for open() mode","author":"indygreg","summary":" ","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":["baymax"],"ccs":["yuja","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117718","dateCreated":"1579887197","dateModified":"1579887197"},{"type":"reject","author":"baymax","id":"117717","dateCreated":"1579887196","dateModified":"1579887196"},{"type":"comment","comment":"I wanna leave it with no prefix as possible. I think we'll have to bulk-replace\n`''`s to `b''`s at some point so we can leverage static analysis tools, where\n`r''` will be unneeded.","author":"yuja","id":"35990","dateCreated":"1518432079","dateModified":"1518432079"},{"type":"comment","comment":"Looks like a better approach will be to revert this change: https:\/\/www.mercurial-scm.org\/repo\/hg\/rev\/7c54917b31f6. I did that in favor of pycompat.open() and now I think it's better to revert that change. ","author":"pulkit","id":"35944","dateCreated":"1518420826","dateModified":"1518420826"},{"type":"update","diffId":"5459","author":"indygreg","id":"35745","dateCreated":"1518402936","dateModified":"1518402936"}],"dateCreated":"1518402936","dateModified":"1579887197","status":"Needs Revision"},{"id":"2622","callsign":"HG","title":"ui: adding a generic method to read config items with an arbitrary type","author":"rdamazio","summary":"This can be used for reading many config options of various types where the\ntype of each is known in some other structure (e.g. options matching command\nflags).","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117715","dateCreated":"1579887195","dateModified":"1579887195"},{"type":"reject","author":"baymax","id":"117714","dateCreated":"1579887195","dateModified":"1579887195"},{"type":"update","diffId":"6520","author":"rdamazio","id":"42415","dateCreated":"1520121279","dateModified":"1520121279"}],"dateCreated":"1520121279","dateModified":"1579887195","status":"Needs Revision"},{"id":"2680","callsign":"HG","title":"[PoC] obsolete: make markers database writable if local-only mode enabled","author":"indygreg","summary":" ","testPlan":"","lineCount":"4","dependsOn":["2679"],"reviewers":["baymax"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117712","dateCreated":"1579887194","dateModified":"1579887194"},{"type":"reject","author":"baymax","id":"117711","dateCreated":"1579887194","dateModified":"1579887194"},{"type":"update","diffId":"6638","author":"indygreg","id":"43217","dateCreated":"1520210574","dateModified":"1520210574"}],"dateCreated":"1520210574","dateModified":"1579887194","status":"Needs Revision"},{"id":"2682","callsign":"HG","title":"[PoC] changegroup: delete obs markers when applying changegroup","author":"indygreg","summary":"In local-only obsolescence mode, our short-term hack to unhide a\nchangeset is to delete obsolescence markers causing it to be hidden.\nWe need to do this every time a changeset is introduced into the\nrepository.\n\nI was hoping we could implement the unhide logic once, around\ntransaction close time. However, it appears that we'll need to\nteach every mechanism that introduces changesets to unhide\nchangesets because of interaction between those mechanisms and\nvisibility. For example, changegroup application no-ops on incoming\nchangesets that are present but hidden. The code that scans for\n\"new\" changesets is based on changesets between the old and new\nchangelog length. Since the unhidden changeset is possibly older\nthan the old changelog length, we need to either track unhides\nexplicitly or deal with them specially.\n\nThis commit teaches changegroup application to record which changesets\nare in the incoming changegroup so it can scan for relevant\nobsolescence markers after changegroup applications and delete\ntheir markers.\n\nI'm not convinced this is the best approach to the problem. But it's\na start.","testPlan":"","lineCount":"27","dependsOn":["2681"],"reviewers":["baymax"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117709","dateCreated":"1579887192","dateModified":"1579887192"},{"type":"reject","author":"baymax","id":"117708","dateCreated":"1579887192","dateModified":"1579887192"},{"type":"update","diffId":"6640","author":"indygreg","id":"43236","dateCreated":"1520210580","dateModified":"1520210580"}],"dateCreated":"1520210580","dateModified":"1579887192","status":"Needs Revision"},{"id":"2681","callsign":"HG","title":"[PoC] scmutil: support local only obsolescence","author":"indygreg","summary":"Now that we have a config option for enabling local-only obsolescence,\nit is time to do something with it.\n\nThis commit teaches cleanupnodes() - which is called after rewrite\noperations - to handle local only obsolescence mode.\n\nIn this mode, we create a backup bundle of the obsoleted changesets -\njust like what happens if obsolescence is disabled. But we don't strip\nthe repo: we keep the original changesets around in a non-visible state.\n\nThe new code verifies that no unstable changesets are introduced in\nlocal-only obsolescence mode.\n\nThe new code hackily only runs if the action is \"amend.\" The intent\nis to make this conditional only on the feature option. However,\ndoing that would have significant test fallout. So we limit to \"amend\"\nfor now.\n\nTODO:\n\n* Better test coverage (I think the \"(testcase !)\" syntax might be\n  subtly wrong by flagging output as optional and not required).\n* Delete obsolescence markers when we pull and unbundle from the\n  bundle.\n* Support pulling locally-hidden heads.","testPlan":"","lineCount":"143","dependsOn":["2680"],"reviewers":["baymax"],"ccs":["mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117706","dateCreated":"1579887191","dateModified":"1579887191"},{"type":"reject","author":"baymax","id":"117705","dateCreated":"1579887191","dateModified":"1579887191"},{"type":"comment","comment":"re: the \"(testcase !)\" syntax- I agree that it would be better if \"(false !)\" means the line is *not* present, instead of optional.\n\nI made an attempt to do that, but somehow I came up with a test in test-run-tests.t that failed there, but the exact same test ran fine in another *.t.  I wondered if it was a case of run-tests.py processing it for a test inside test-run-tests.t, and then the main instance of run-tests.py re-processing it.  If I can find that code, I can post it if you think it might be useful.  But I've long forgotten the nuance in that code. ","author":"mharbison72","id":"43337","dateCreated":"1520216552","dateModified":"1520216552"},{"type":"update","diffId":"6639","author":"indygreg","id":"43226","dateCreated":"1520210577","dateModified":"1520210577"}],"dateCreated":"1520210577","dateModified":"1579887191","status":"Needs Revision"},{"id":"2588","callsign":"HG","title":"commit: adds multiline commit message support(issue5616)","author":"sangeet259","summary":"The earlier functionality used to ignore the all but last -m flag's value.\nIt used to store the arguments information in a state dict and then overwrites each\nsubsequent value of -m in the 'message' key. This patch intercepts the message flag and\nchecks if it is already empty. In case it is not empty, add the current value of -m flag to\nthe message key with a leading '\\n' character. This makes every subsequent passed -m flag\nas the new line message of the commit.","testPlan":"","lineCount":"28","dependsOn":[],"reviewers":["baymax"],"ccs":["durin42","tom.prince","yuja","pulkit","jeffpc","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117703","dateCreated":"1579887189","dateModified":"1579887189"},{"type":"reject","author":"baymax","id":"117702","dateCreated":"1579887189","dateModified":"1579887189"},{"type":"comment","comment":">>! In D2588#44645, @sangeet259 wrote:\n> Since the current code just overwrites message each time with the newer. What can be done to avoid losing the earlier message values?\n\nYou should look how we handle multiple `--rev` flags. That will help you in this case.","author":"pulkit","id":"44677","dateCreated":"1520666278","dateModified":"1520666278"},{"type":"comment","comment":"Since the current code just overwrites message each time with the newer. What can be done to avoid losing the earlier message values?\n","author":"sangeet259","id":"44645","dateCreated":"1520655918","dateModified":"1520655918"},{"type":"inline","comment":"agreed","replyTo":"42705","isNewFile":"1","line":"847","lineLength":"0","path":"tests\/test-commit.t","diffId":"6537","author":"durin42","id":"43618","dateCreated":"1520437801","dateModified":"1520437801"},{"type":"comment","comment":"@pulkit Yeah, this rather a not so elegant hack. How can it be parsed in hg commit? \nAs the first message passed is overwritten by the second one at this step only.  :\/\n\n@yuja I think maybe subclassing the customopt may be a fair choice.","author":"sangeet259","id":"43614","dateCreated":"1520437520","dateModified":"1520437520"},{"type":"inline","comment":"Right. Alternatively, we could add a subclass of customopt, but I don't know which\nwould be nicer.\n\nFWIW, I'm kinda -1 on this feature, but I have no strong opinion and Git is the\ncurrent standard.","replyTo":"42704","isNewFile":"1","line":"365","lineLength":"0","path":"mercurial\/fancyopts.py","diffId":"6537","author":"yuja","id":"42772","dateCreated":"1520184244","dateModified":"1520184244"},{"type":"inline","comment":"starting with a newline seems awkward.","replyTo":null,"isNewFile":"1","line":"847","lineLength":"0","path":"tests\/test-commit.t","diffId":"6537","author":"pulkit","id":"42705","dateCreated":"1520181862","dateModified":"1520181862"},{"type":"inline","comment":"I think this is not the right place to have this hack. We should have this as a part of `hg commit` code rather.","replyTo":null,"isNewFile":"1","line":"365","lineLength":"0","path":"mercurial\/fancyopts.py","diffId":"6537","author":"pulkit","id":"42704","dateCreated":"1520181862","dateModified":"1520181862"},{"type":"update","diffId":"6537","author":"sangeet259","id":"42559","dateCreated":"1520149348","dateModified":"1520149348"},{"type":"comment","comment":"@jeffpc That means two new lines. Shall I edit this patch to effect that?\n","author":"sangeet259","id":"42558","dateCreated":"1520142981","dateModified":"1520147672"},{"type":"update","diffId":"6536","author":"sangeet259","id":"42557","dateCreated":"1520139879","dateModified":"1520139879"},{"type":"comment","author":"sangeet259","id":"41893","dateCreated":"1520098879","dateModified":"1520098898"},{"type":"comment","comment":"FWIW, this is slightly different behavior from what git does.  There, each -m is added as a separate *paragraph*.  IOW,\n\n\n```\n$ git commit -m \"first\" -m \"second\"\n```\n\ncreates:\n\n```\nfirst\n\nsecond\n```","author":"jeffpc","id":"41892","dateCreated":"1520098727","dateModified":"1520098727"},{"type":"update","diffId":"6438","author":"sangeet259","id":"41882","dateCreated":"1520098029","dateModified":"1520098029"}],"dateCreated":"1520098029","dateModified":"1579887189","status":"Needs Revision"},{"id":"2057","callsign":"HG","title":"rust implementation of hg status","author":"Ivzhh","summary":"* implementation of revlog v1\n* parsing changelog, manifest, dirstate\n* use .hgignore in repo root\n* comparable performance with current hg status (Linux & Mac: slightly faster, Windows: slightly slower)\n* use hg r-status as subcommand, in this case, bypass python engine","testPlan":"","lineCount":"3066","dependsOn":[],"reviewers":["kevincox","baymax"],"ccs":["quark","yuja","glandium","krbullock","indygreg","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117700","dateCreated":"1579887188","dateModified":"1579887188"},{"type":"reject","author":"baymax","id":"117699","dateCreated":"1579887188","dateModified":"1579887188"},{"type":"inline","comment":"I meant safe not as it it didn't need the unsafe keyword, but in that the use of the `unsafe` block is safe.\n\nIt should really be called the `trust_me,_I_know_this_is_safe` block. But since you are not getting the compiler checking it is often useful to add a comment why the action you are performing is correct. In this case it is correct because the caller initializes this variable before the function is called.","replyTo":"46950","isNewFile":"1","line":"91","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"47428","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Actually I didn't realize that RwLock doesn't get a regular `get()` since it is doing a compile time borrow check. https:\/\/doc.rust-lang.org\/std\/sync\/struct.RwLock.html#method.get_mut. My mistake, the code is fine.","replyTo":"46960","isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"47427","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Does it make sense to make `DirStateEntry.mtime` be a `std::time::SystemTime` and convert upon reading the structure in?\n\nIf not I would prefer doing the conversion here:\n\n```\nelse if mtd.modified().unwrap() == UNIX_EPOCH + Duration::from_secs(dir_entry.mtime as u64) {\n```\n\n(Maybe extract the system time to higher up, or even a helper function on dir_entry)","replyTo":null,"isNewFile":"1","line":"263","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"7188","author":"kevincox","id":"47426","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Sorry, I misunderstood the logic. You can do this:\n\n```\ndiff -r ccc683587fdb rust\/hgstorage\/src\/dirstate.rs\n--- a\/rust\/hgstorage\/src\/dirstate.rs\tSat Mar 24 10:05:53 2018 +0000\n+++ b\/rust\/hgstorage\/src\/dirstate.rs\tSat Mar 24 10:14:58 2018 +0000\n@@ -184,8 +184,7 @@\n                         continue;\n                     }\n \n-                    if self.dir_state_map.contains_key(rel_path) {\n-                        let dir_entry = &self.dir_state_map[rel_path];\n+                    if let Some(dir_entry) = self.dir_state_map.get(rel_path) {\n                         files_not_in_walkdir.remove(rel_path);\n                         DirState::check_status(&mut res, abs_path, rel_path, dir_entry);\n                     } else if !matcher.check_path_ignored(rel_path.to_str().unwrap()) {\n```","replyTo":"46959","isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"47425","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Switch the return type to `std::io::Result` and then you can have\n\n```\nlet metadata = p.metadata()?;\nlet mtime = metadata.modified()?;\n\/\/ ...\n```","replyTo":null,"isNewFile":"1","line":"103","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"7188","author":"kevincox","id":"47424","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"A link to the mentioned wiki page would be very helpful to readers.","replyTo":null,"isNewFile":"1","line":"50","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"7188","author":"kevincox","id":"47423","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"These are `HashSet`'s which don't have a defined iterator order. IIRC the python implementation sorts the results which is probably desirable.","replyTo":null,"isNewFile":"1","line":"260","lineLength":"0","path":"rust\/hgcli\/src\/main.rs","diffId":"7188","author":"kevincox","id":"47422","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"If this computation only depends on `len` it would be nice to put it in a helper function.","replyTo":null,"isNewFile":"1","line":"105","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"7188","author":"kevincox","id":"47421","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"I get that, but I still think it makes the code easier to read when the python-interop and the logic as separated where it is easy to do so.","replyTo":"46947","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"47420","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"comment","comment":"The latest changes are looking really good. I have a couple more comments but I didn't have time for a full review. I'll try to get more reviewed tomorrow. It seems that you still have a lot of stuff still in-flight so I'll try to slowly review the changes as I have time. If you want input\/feedback on any particular part just ask and I will prioritize it.\n\nThis change is very large so it might be worth splitting off a smaller component and getting that submitted first. However I do realize that for starting out it is often helpful to get some actual use cases implemented before committing the base structures.","author":"kevincox","id":"47419","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"comment","comment":">>! In D2057#46980, @Ivzhh wrote:\n>>>! In D2057#46726, @yuja wrote:\n>>>> I think the only place where you would need to do os-specific code is when\n>>>> doing serialization and serialization\n>>> \n>>> Yes, that will be feasible in strictly typed language like Rust.\n>> \n>> To be clear, I meant serialization\/deserialization between filesystem path and\n>> internal dirstate\/manifest path, not between dirstate storage and in-memory\n>> dirstate object.\n> \n> I guess your suggestion is like this: @yuja\n> \n> 1. if it is windows and the code page is MBCS, try to decode the paths read from manifest and dirstate into unicode equivalent\n> 2. use utf internally and with rust IO api\n> 3. when writing back to dirstate and manifest, encode utf to MBCS\n\nNo. My suggestion is:\n\n1. keep manifest\/dirstate paths as bytes (which are probably wrapped by some type, say HgPath)\n2. but we want to use Rust's standard library for I\/O\n3. so, add utility function\/trait to convert HgPath to Path\/PathBuf, where MBCS-Wide conversion\n   will occur.\n\nI think raw byte paths will be needed to build store paths (e.g. `.hg\/store\/data\/~2eclang-format.i`).\n\nhttps:\/\/www.mercurial-scm.org\/repo\/hg\/file\/4.5.2\/mercurial\/store.py","author":"yuja","id":"47287","dateCreated":"1521730814","dateModified":"1521730814"},{"type":"comment","comment":">>! In D2057#46726, @yuja wrote:\n>>> I think the only place where you would need to do os-specific code is when\n>>> doing serialization and serialization\n>> \n>> Yes, that will be feasible in strictly typed language like Rust.\n> \n> To be clear, I meant serialization\/deserialization between filesystem path and\n> internal dirstate\/manifest path, not between dirstate storage and in-memory\n> dirstate object.\n\nI guess your suggestion is like this: @yuja\n\n1. if it is windows and the code page is MBCS, try to decode the paths read from manifest and dirstate into unicode equivalent\n2. use utf internally and with rust IO api\n3. when writing back to dirstate and manifest, encode utf to MBCS\n\nPlease let me know if I have misunderstanding. Thank you!","author":"Ivzhh","id":"46981","dateCreated":"1521662441","dateModified":"1521662461"},{"type":"inline","comment":"I guess I did this because I met some empty change delta in the beginning. I think I won't try to parallelize unzip for now.","replyTo":"43866","isNewFile":"1","line":"290","lineLength":"3","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"Ivzhh","id":"46964","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I think it explains why in mercurial repo, rust version is significantly faster. I am working on cpu future, but I did not finalize design style yet. I will keep working on that.","replyTo":"43867","isNewFile":"1","line":"279","lineLength":"0","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"Ivzhh","id":"46963","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"This part, including the stream-style, is from python part. I will update later with xi-rope.","replyTo":"43969","isNewFile":"1","line":"51","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"Ivzhh","id":"46962","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I borrow this logic as whole from python code. It will need sometime to re-translate to non-pointer-arithmetic way.","replyTo":"43949","isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"Ivzhh","id":"46961","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I think LRU will update reference count (or timestamp) when the data is accessed.","replyTo":"43942","isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"Ivzhh","id":"46960","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I kind of get borrow check compile error here. Later I use Occupied() when possible.","replyTo":"43930","isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46959","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I add the error handling back","replyTo":"43923","isNewFile":"1","line":"161","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46958","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"For the filter, I follow the example in the walkdir doc. I guess what I want is to skip the dir for later recursive visiting. ","replyTo":"43921","isNewFile":"1","line":"152","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46957","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I think dir state needs to 1. read existing one; 2. create one if not exits; maybe private for now.","replyTo":"43916","isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46956","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I remember the python hg uses the name, in the beginning, I tried to replicate py-hg's behaviour. But I think it needs to be renamed. I agree with you.","replyTo":"43928","isNewFile":"1","line":"48","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46955","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I like to_owned(), I will them in later occasions. Thank you!","replyTo":"43913","isNewFile":"1","line":"78","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"Ivzhh","id":"46954","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"Sure, I will use v1 only for now. In the beginning I kinda over designed this part.","replyTo":"43865","isNewFile":"1","line":"95","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"Ivzhh","id":"46953","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I guess I will use the rest info later. hg seems put some meta data in the commit comments. I will keep it for now. Thank you!","replyTo":"43911","isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"Ivzhh","id":"46952","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"Thank you for the suggestion! I guess I need to extend clap later to support hg style command line. Right now whenever clap cannot handle the argument parsing, I will redirect the arguments to hg directly.","replyTo":"43864","isNewFile":"1","line":"233","lineLength":"28","path":"rust\/hgcli\/src\/main.rs","diffId":"6724","author":"Ivzhh","id":"46951","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"when I removed the unsafe, I got error: error[E0133]: use of mutable static requires unsafe function or block","replyTo":"43908","isNewFile":"1","line":"91","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46950","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I guess it is because NLL. When I started the work, rust compiler reported borrow check error on this part. I later read an article talking about NLL update in rust. But before that, I use the braces to avoid the error.","replyTo":"43901","isNewFile":"1","line":"46","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46949","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"pad is a bool, however when I checked it in hg-python, int are passed to the function. I guess I need to update cpython wrapper for this, a more broad logic conversion.","replyTo":"43900","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46948","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"This crate is my previous try to integrate rust into hg. Right now I guess mine main pursue is to add hg r-* commands for rust. I will follow your suggestion when I am implementing the wire protocol and reuse the code for pure rust crate.","replyTo":"43897","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46947","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"It should be any &[u8], but the current cpython crate doesn't wrap for &[u8]. I think I need to fork and add that part. I put it in my checklist now.","replyTo":"43898","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46946","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"comment","comment":"  - add revlog and mpatch facilities\n  - add changelog parsing\n  - add manifest parsing\n  - path encoding for data store\n  - add dirstate and matcher facilities\n  - add local repository and the supporting modules\n  - use cargo fmt to format code\n  - add hg r-status command\n  - bincode 1.0.0 is a bit slow in my test\n  - delay pattern matching during dir walk\n  - optimize out trie and enable CoreXL profiling\n  - use hashmap\n  - remove thread pool\n  - rust default read is not buf-ed, this is the key of slowness\n  - change to globset\n  - convert glob to regex\n  - hg ignore patterns are all converted to regex (as hg does), and now it is faster\n  - filter dir early to prevent walking\n  - Update matcher mod after testing Mozilla unified repo\n  - bug fix: use byte literals instead of numbers\n  - hg store path encoding is per byte style, update code according to Kevin Cox's comments\n  - update matcher testing according to Match interface change\n  - If clap fails to recognize r-* subcommands, then run python-version hg\n  - changelog coding style revised\n  - remove legacy revlog v0 and unfinished v2.\n  - partially revise the dirstate reviews\n  - remove duplicated build.rs, let the executable module guarantee the python\n  - use cursor in base85 encoding, reducing raw index-math\n  - use cursor in base85 decoding, reducing raw index-math\n  - dirstate update according to review comments\n  - config update according to review comments\n  - mpatch rename to more meaningful names\n  - simplify matcher as when there is no syntax named in the beginning, use regexp\n  - local repo coding style update\n  - dirstate coding style update\n  - manifest coding style update\n","author":"Ivzhh","id":"46944","dateCreated":"1521656608","dateModified":"1521656608"},{"type":"update","diffId":"7188","author":"Ivzhh","id":"46942","dateCreated":"1521656608","dateModified":"1521656608"},{"type":"comment","comment":"Ah, I forgot to consider the python interop. Now the need for that crate makes sense. Thanks for explaining.","author":"kevincox","id":"46733","dateCreated":"1521627628","dateModified":"1521627628"},{"type":"comment","comment":">> I think the only place where you would need to do os-specific code is when\n>> doing serialization and serialization\n> \n> Yes, that will be feasible in strictly typed language like Rust.\n\nTo be clear, I meant serialization\/deserialization between filesystem path and\ninternal dirstate\/manifest path, not between dirstate storage and in-memory\ndirstate object.","author":"yuja","id":"46726","dateCreated":"1521613817","dateModified":"1521613817"},{"type":"comment","comment":"> I think the only place where you would need to do os-specific code is when\n> doing serialization and serialization\n\nYes, that will be feasible in strictly typed language like Rust.\n\n> which I think should be handled by https:\/\/doc.rust-lang.org\/std\/os\/unix\/ffi\/trait.OsStringExt.html\n> and https:\/\/doc.rust-lang.org\/std\/os\/windows\/ffi\/trait.OsStringExt.html.\n\nNot true for Windows because Rust uses Unicode (UTF-16-ish) API, whereas\nPython 2 does ANSI. We need to convert a \"wide\" string to a locale-dependent string.\n\nMaybe the local-encoding crate will do that for us?\n\n","author":"yuja","id":"46723","dateCreated":"1521607475","dateModified":"1521607475"},{"type":"comment","comment":"I'm not a windows expert but it seems like the rust OsStr, Path and filesystem APIs should handle these conversions for you. I think the only place where you would need to do os-specific code is when doing serialization and serialization which I think should be handled by https:\/\/doc.rust-lang.org\/std\/os\/unix\/ffi\/trait.OsStringExt.html and https:\/\/doc.rust-lang.org\/std\/os\/windows\/ffi\/trait.OsStringExt.html.","author":"kevincox","id":"46685","dateCreated":"1521577349","dateModified":"1521577349"},{"type":"comment","comment":"https:\/\/crates.io\/crates\/local-encoding seems to be the right choice.","author":"quark","id":"46681","dateCreated":"1521573831","dateModified":"1521573831"},{"type":"comment","comment":"> I am looking at Mozilla's rust winapi bindings, let me see if I can directly wrap around [winapi::um::fileapi::FindFirstFileA](https:\/\/docs.rs\/winapi\/*\/x86_64-pc-windows-msvc\/winapi\/um\/fileapi\/fn.FindFirstFileA.html)\n\nThat's probably a hard way. I was thinking of something converting\nbetween OsStr (i.e. Path) and MBCS bytes by using Win32 API, instead\nof calling out the \"A\" API.\n\nhttps:\/\/msdn.microsoft.com\/en-us\/library\/windows\/desktop\/dd319072(v=vs.85).aspx\n\nWe don't do that in Python, but Rust's type system will help making it right.","author":"yuja","id":"44688","dateCreated":"1520680806","dateModified":"1520680806"},{"type":"comment","comment":">>! In D2057#44269, @yuja wrote:\n>>> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n>> \n>> IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n> \n> It's MBCS (i.e. ANSI multi-byte characters) on Windows. The plain was to support\n> both MBCS and UTF-8-variant on Windows, but that isn't a thing yet.\n> \n> Perhaps we'll have to write a platform compatibility layer (or serialization\/deserialization\n> layer) on top of the Rust's file API, something like vfs.py we have in Python code.\n\nThank you for confirming that, I am a bit confusing when I read Encoding Plan wiki page. I am looking at Mozilla's rust winapi bindings, let me see if I can directly wrap around [winapi::um::fileapi::FindFirstFileA](https:\/\/docs.rs\/winapi\/*\/x86_64-pc-windows-msvc\/winapi\/um\/fileapi\/fn.FindFirstFileA.html)","author":"Ivzhh","id":"44295","dateCreated":"1520618349","dateModified":"1520618349"},{"type":"comment","comment":">> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n> \n> IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n\nIt's MBCS (i.e. ANSI multi-byte characters) on Windows. The plain was to support\nboth MBCS and UTF-8-variant on Windows, but that isn't a thing yet.\n\nPerhaps we'll have to write a platform compatibility layer (or serialization\/deserialization\nlayer) on top of the Rust's file API, something like vfs.py we have in Python code.","author":"yuja","id":"44270","dateCreated":"1520598781","dateModified":"1520598781"},{"type":"comment","comment":"Hi everyone,\n\nThank you for your encouragements and comments! I will follow up with all comments and update the code soon.\n\n@indygreg It is a great idea to test on Mozilla repo, actually I found several things interesting:\n\n1. I found a bug in my code (shame on me): because I did not use byte literal, and I made a typo. This triggers problem in Mozilla unified repo\n2. A regexp pattern in hgignore in Mozilla unified repo is not supported by rust's regex crate, a.k.a. \"(?!)\". I choose to ignore these unsupported patterns.\n3. My version is slower in this repo: 70s (hg) and 90s (mine). CodeXL reveals that the mpatch::collect() function uses 63% of the running time. I think I need to optimize it somehow.\n\nI totally agree with @kevincox that I did not sort well on char\/u8\/str\/String\/Path\/PathBuf. The first bug is caused by this. I need to improve them.\n\nThank you everyone!","author":"Ivzhh","id":"44180","dateCreated":"1520558265","dateModified":"1520558265"},{"type":"comment","comment":"Rust has platform independent types [[ https:\/\/doc.rust-lang.org\/stable\/std\/path\/struct.PathBuf.html | `PathBuf` ]] and [[ https:\/\/doc.rust-lang.org\/stable\/std\/path\/struct.Path.html | `&Path` ]] for paths and [[ https:\/\/doc.rust-lang.org\/stable\/std\/ffi\/struct.OsString.html | `OsString` ]] and [[ https:\/\/doc.rust-lang.org\/stable\/std\/ffi\/struct.OsStr.html | `&OsStr` ]] for strings (owned and references respectively. They do have os-specific extensions but as long as you don't use them it should be cross platform. That being said, if you are serializing and deserializing them you may need to write some platform dependant code.","author":"kevincox","id":"43991","dateCreated":"1520536377","dateModified":"1520536377"},{"type":"comment","comment":">>! In D2057#43989, @durin42 wrote:\n>>>! In D2057#43988, @kevincox wrote:\n>>>>! In D2057#43987, @durin42 wrote:\n>>> \n>>> Mercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?\n>> \n>> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n> \n> IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n> \n> We may have to make adjustments to this plan on macOS with APFS, but I'm not sure about that yet.\n\nI think we want to express a path as a dedicated type which has different underlying storage depending on the platform (bytes on Linux, UTF-16 on Windows). All filesystem operations should take a `Path` instance to operate on. This is the only way to cleanly round trip filenames between the OS, the application, and back to the OS. That leaves us with the hard problem of normalizing Mercurial's storage representation of paths (bytes) with the operating system's. But this world is strictly better than today, where we lose path data from the OS because we use POSIX APIs.\n\nFWIW, Python 3 rewrote the I\/O layer to use Win32 APIs everywhere. Combined with the `pathlib` types, I'm pretty sure Python 3 can round trip paths on Windows. I also think Rust's path type(s) have OS-dependent functionality.","author":"indygreg","id":"43990","dateCreated":"1520534077","dateModified":"1520534077"},{"type":"comment","comment":">>! In D2057#43988, @kevincox wrote:\n>>>! In D2057#43987, @durin42 wrote:\n>> \n>> Mercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?\n> \n> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n\nIIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n\nWe may have to make adjustments to this plan on macOS with APFS, but I'm not sure about that yet.","author":"durin42","id":"43989","dateCreated":"1520533145","dateModified":"1520533145"},{"type":"comment","comment":">>! In D2057#43987, @durin42 wrote:\n> \n> Mercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?\n\nReading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.","author":"kevincox","id":"43988","dateCreated":"1520532520","dateModified":"1520532520"},{"type":"comment","comment":">>! In D2057#43892, @kevincox wrote:\n> On a higher level, all of these code appears to be treating file names as strings. This isn't really true and will disallow some valid file names. Maybe we should stick with bytes throughout. Of course this makes windows filepaths difficult because they are actually (utf16) strings.\n\nMercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?","author":"durin42","id":"43987","dateCreated":"1520531899","dateModified":"1520531899"},{"type":"inline","comment":"Take a `&str`.","replyTo":null,"isNewFile":"1","line":"62","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43985","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nfn escape(out: &mut String, b: char) {\n    unimplemented!()\n}\n\npub fn encode_path(path: &str) -> String {\n    let mut out = String::with_capacity(path.len());\n\n    for c in path.bytes() {\n        let c = c as char;\n        match c {\n            'A'...'Z' => {\n                out.push('_');\n                out.push(c.to_ascii_lowercase());\n            }\n            '\\\\' | ':' | '*' | '?' | '\"' | '<' | '>' | '|' => {\n                escape(&mut out, c);\n            }\n            \/\/ The rest of the printable range.\n            ' '...'~' => {\n                out.push(c);\n            }\n            _ => {\n                escape(&mut out, c);\n            }\n        }\n    }\n\n    out\n}\n```\nhttps:\/\/godbolt.org\/g\/3WCQs3","replyTo":null,"isNewFile":"1","line":"57","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43984","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Don't pass a `char` by reference. Also it seems your function wants a `u8`.","replyTo":null,"isNewFile":"1","line":"11","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43983","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Use a String.","replyTo":null,"isNewFile":"1","line":"35","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43982","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`encode_file_name`?","replyTo":null,"isNewFile":"1","line":"34","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43981","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Take a `&str`","replyTo":null,"isNewFile":"1","line":"34","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43980","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\np.ends_with(\".i\") || p.ends_with(\".d\")\n```","replyTo":null,"isNewFile":"1","line":"25","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43979","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This isn't necessary.","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43978","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I don't think you need this.","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43977","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`Vec<char>` is odd. Is there any reason not to use a `String` or `Vec<u8>`","replyTo":null,"isNewFile":"1","line":"11","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43976","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"c should be a `u8`.","replyTo":null,"isNewFile":"1","line":"7","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43975","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"const HEX_DIGIT: [u8; 16] = *b\"0123456789abcdef\";","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43974","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nassert!(!frags.is_empty());\n```","replyTo":null,"isNewFile":"1","line":"137","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43973","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Please explain.","replyTo":null,"isNewFile":"1","line":"120","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43972","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Make this one line and don't bother renaming.","replyTo":null,"isNewFile":"1","line":"86","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43971","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nfor &Fragment{frag_len, frag_ofs} in list.iter().rev()\n```","replyTo":null,"isNewFile":"1","line":"68","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43970","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"It seems weird to take a cursor to a vec if you are just going to do an absolute seek. Can it work with `&mut [u8]`?","replyTo":null,"isNewFile":"1","line":"51","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43969","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`vec![0; count]` works. (The arguments might be the other way around).","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43968","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`mov` is overly shortened and generic.","replyTo":null,"isNewFile":"1","line":"51","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43967","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`pull` is very generic.","replyTo":null,"isNewFile":"1","line":"35","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43966","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nstruct Fragment {\n    len: u32,\n    offset: u32,\n}\n```","replyTo":null,"isNewFile":"1","line":"24","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43965","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/f\/fragment\/","replyTo":null,"isNewFile":"1","line":"40","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43964","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are unwrapping the `pop` there is no need for the prior check.","replyTo":null,"isNewFile":"1","line":"40","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43963","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Maybe it's just me but I think it is more common to put the source before the destination.","replyTo":null,"isNewFile":"1","line":"35","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43962","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nassert!(!src.is_empty())\n```","replyTo":null,"isNewFile":"1","line":"39","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43961","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Spell these out please.","replyTo":null,"isNewFile":"1","line":"13","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43960","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would do `self.inner.map(|m| m.is_match(rp)).unwrap_or(false)` but this is fine.","replyTo":null,"isNewFile":"1","line":"200","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43959","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/rp\/path\/","replyTo":null,"isNewFile":"1","line":"195","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43958","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/relglob\/relative_glob_re\/","replyTo":null,"isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43957","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Is this a warning or error? You might want to switch to `panic!`.","replyTo":null,"isNewFile":"1","line":"159","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43956","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would move this into the following match because it dedupes the `starts_with` check and puts the logic closer together.","replyTo":null,"isNewFile":"1","line":"160","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43955","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/ln\/line\/","replyTo":null,"isNewFile":"1","line":"143","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43954","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Better name please.","replyTo":null,"isNewFile":"1","line":"131","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43953","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You should be able to do `&string` rather then `string.as_str()` as it coerces. ","replyTo":null,"isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43952","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are just doing one call just return the result.","replyTo":null,"isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43951","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are going to call `String.as_str()` just take a `&str`.","replyTo":null,"isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43950","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Can you manage a `&[u8]` rather then pointer arithmetic for the whole string. It will make me feel better and will probably be easier to read.","replyTo":null,"isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43949","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Might be worth calling `String::with_capacity(pat.len())` since it will be at least that long.","replyTo":null,"isNewFile":"1","line":"10","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43948","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/pat\/glob\/","replyTo":null,"isNewFile":"1","line":"9","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43947","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"What are these numbers?","replyTo":null,"isNewFile":"1","line":"49","lineLength":"0","path":"rust\/hgstorage\/src\/manifest.rs","diffId":"6724","author":"kevincox","id":"43946","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/ent\/entry\/","replyTo":null,"isNewFile":"1","line":"42","lineLength":"0","path":"rust\/hgstorage\/src\/manifest.rs","diffId":"6724","author":"kevincox","id":"43945","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"What are these magic numbers?","replyTo":null,"isNewFile":"1","line":"33","lineLength":"0","path":"rust\/hgstorage\/src\/manifest.rs","diffId":"6724","author":"kevincox","id":"43944","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This test has no assetions. Consider calling it `test_create_...` or something to indicate that you are just checking for panics.","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43943","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Why does it need to be mutable to clone?","replyTo":null,"isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43942","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/fp\/path\/","replyTo":null,"isNewFile":"1","line":"121","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43941","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`gd` is cryptic.","replyTo":null,"isNewFile":"1","line":"129","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43940","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nassert!(abspath.exists(), \"path not exists: {:?}\", abspath);\n```","replyTo":null,"isNewFile":"1","line":"127","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43939","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nwhile !root.join(\".hg\").exists() {\n    root = root.parent().expect(\".hg folder not found\");\n}\n```","replyTo":null,"isNewFile":"1","line":"66","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43938","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would replace the condition with.\n\n```\nassert!(dot_hg_path.exists(), \".hg folder not found for the path given by -R argument: {:?}\", p);\n```","replyTo":null,"isNewFile":"1","line":"50","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43937","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You can add a later `.arg(dst)` to support non-utf8 paths instead of converting to a str here.","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hgstorage\/src\/lib.rs","diffId":"6724","author":"kevincox","id":"43936","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"In rust we generally avoid brackets around `as` as it is very tightly binding.","replyTo":null,"isNewFile":"1","line":"206","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43935","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Please use a better name for `sent`.","replyTo":null,"isNewFile":"1","line":"199","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43934","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You can use the entry api here.","replyTo":null,"isNewFile":"1","line":"184","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43933","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/rem\/path\/ or remaining_path.","replyTo":null,"isNewFile":"1","line":"183","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43932","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Use an `else if`.","replyTo":null,"isNewFile":"1","line":"175","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43931","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You could do the following for a slight performance win and save a line.\n\n```\nif let Occupied(entry) = self.dmap.entry(relpath) {\n   ...\n}\n```","replyTo":null,"isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43930","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I recommend not renaming this. It is confusing.","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43929","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This could have a better name.","replyTo":null,"isNewFile":"1","line":"48","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43928","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nlet mut grey = Set::new();\ngrey.extend(self.dmap.keys().map(|s| s.as_path()));\n```\n\nAlso I would pick a name like `undiscovered_paths` or something. `grey` is cryptic.","replyTo":null,"isNewFile":"1","line":"146","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43927","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would also put this filter above. But more importantly all `_is_bad()` does is check for file types. So it seems like the former filter is redundant with this one.","replyTo":null,"isNewFile":"1","line":"169","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43926","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would move this filter beside the filter in the loop.","replyTo":null,"isNewFile":"1","line":"167","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43925","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would just call this `path` or `pathbuf`.","replyTo":null,"isNewFile":"1","line":"162","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43924","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Please explain why you are ignoring the error condition.","replyTo":null,"isNewFile":"1","line":"161","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43923","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This is probably worth a helper function.","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43922","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would prefer doing the filter before the loop and storing it in a variable.","replyTo":null,"isNewFile":"1","line":"152","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43921","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/mtc\/matcher\/","replyTo":null,"isNewFile":"1","line":"141","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43920","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Don't use `_` prefix for privates. Rely on rust viability. \n\nAlso `is_bad` isn't very informative.","replyTo":null,"isNewFile":"1","line":"130","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43919","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Is ignoring duplicate entries desired? It might be worth a comment explaining why.","replyTo":null,"isNewFile":"1","line":"125","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43918","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This should Probably return a `Result<Self>` and pass the error to the caller.","replyTo":null,"isNewFile":"1","line":"87","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43917","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"1. Does this function need to be public? It seems internal to the constructor.\n1. If it doesn't need to be I would prefer it return the Map so that you don't have a partial-constructed DirState.","replyTo":null,"isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43916","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would skip this check and rely on `p.metadata()`. Just switch `.unwrap()` to `.expect()` with a nicer message. This also handles race conditions more nicely.","replyTo":null,"isNewFile":"1","line":"90","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43915","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Is this used yet? It probably also needs some documentation because I don't really understand the fields (but I do have little domain knowledge).","replyTo":null,"isNewFile":"1","line":"49","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"kevincox","id":"43914","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are just going to convert to String I would recommend taking a String argument.\n\nAlso prefer `.to_owned()` over `.to_string()`.","replyTo":null,"isNewFile":"1","line":"78","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"kevincox","id":"43913","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Just put `msg: content` in the struct construction.","replyTo":null,"isNewFile":"1","line":"33","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"kevincox","id":"43912","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you aren't using the value I would prefer `truncate(NodeId::hex_len())`","replyTo":null,"isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"kevincox","id":"43911","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Passing a message as a third argument is really useful.","replyTo":null,"isNewFile":"1","line":"24","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"kevincox","id":"43910","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Let rust do the overflow checking.\n\n```\nacc = acc.checked_mul(85)\n    .ok_or_else(|| {\n        PyErr::new::<exc::ValueError, _>(\n            py,\n            format!(\"bad base85 character at position {}\", i))\n    })?;","replyTo":null,"isNewFile":"1","line":"152","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43909","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This is probably worth a comment that this is safe because D85DEC is required to be initialized before this function is called.","replyTo":null,"isNewFile":"1","line":"91","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43908","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```while !ptext.is_empty()```","replyTo":null,"isNewFile":"1","line":"52","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43907","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"It might be best to use a [[ https:\/\/doc.rust-lang.org\/stable\/std\/io\/struct.Cursor.html | `std::io::Cursor` ]] and let it drack `dst_off` for your.","replyTo":null,"isNewFile":"1","line":"47","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43906","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`ptext` isn't very descriptive. ","replyTo":null,"isNewFile":"1","line":"45","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43905","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"Tracking len manually is a smell. Why not drop it and use `ptest.is_empty()`.","replyTo":null,"isNewFile":"1","line":"63","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43904","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I would prefer the name `chunk` or even `accum` is a lot mode obvious to me than `acc`.","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43903","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I suspect this type annotation isn't required.","replyTo":null,"isNewFile":"1","line":"47","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43902","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"Why the braces here?","replyTo":null,"isNewFile":"1","line":"46","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43901","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"IIUC pad is only ever checked `== 0`. Can it be made into a bool?","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43900","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I would just combine these into one line as the name `ch` isn't adding much.","replyTo":null,"isNewFile":"1","line":"58","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43899","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"`&str` can only hold valid utf8 data? Does it make more sense to have `&[u8]` here for a list of bytes?","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43898","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"Would it be possible to separate the decode from the python objects. I'm thinking two helper functions.\n\n```\nfn b85_required_len(text: &str) -> usize\nfn b85_encode(text: &str, pad: i32, out: &mut [u8]) -> Result<()>\n```\n\n","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43897","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"```\nfor i in &[24, 16, 8, 0]\n```","replyTo":null,"isNewFile":"1","line":"56","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43896","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I prefer something like this: https:\/\/play.rust-lang.org\/?gist=5ca18a5b95335600e911b8f9310ea5c7&version=stable\n\nI doubt lazy_static is too slow. Otherwise we can stay like this until const functions get implemented.\n\nEither way note:\n* I changed the type of B85CHARS to an array as opposed to an array ref.\n* The loop condition is much nicer.","replyTo":null,"isNewFile":"1","line":"21","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43895","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"If this is going to be reused I would move it into it's own crate. It seems like everything here could be boiled down to a single function call in main.","replyTo":"43863","isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hgbase85\/build.rs","diffId":"6724","author":"kevincox","id":"43894","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"comment","comment":"I will try to finish the review later, but it might be quicker if you incorporate some of the changes first since a lot of them are repeated many times. Overall it looks good, there are a couple of things that i would highlight to make the code easier to read.\n\n* Prefer more descriptive variable names.\n* If you can, avoid \"pointer\" arithmetic. Cursors and slices are nice and have great convenience methods.\n* Group your flow control and filtering more.\n* Try to keep your types straight. In rust using the right types helps catch errors. So be aware of `char` vs `u8` vs `String` vs `Vec<char>` vs `Vec<u8>`.\n\nOn a higher level, all of these code appears to be treating file names as strings. This isn't really true and will disallow some valid file names. Maybe we should stick with bytes throughout. Of course this makes windows filepaths difficult because they are actually (utf16) strings.","author":"kevincox","id":"43893","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"reject","author":"kevincox","id":"43892","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"comment","comment":"Doesn't mononoke have code to read revlogs already?","author":"glandium","id":"43869","dateCreated":"1520495348","dateModified":"1520495348"},{"type":"inline","comment":"IIRC, core Mercurial keeps an open file handle on revlogs and ensures we don't run out of file handles by not keeping too many revlogs open at the same time. For scanning operations, not having to open and close the file handles all the time will make a difference for performance. Also, core Mercurial loads the entirety of the `.i` file into memory. That's a scaling problem for large revlogs. But it does make performance of index lookups really fast.","replyTo":null,"isNewFile":"1","line":"279","lineLength":"0","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"indygreg","id":"43867","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"A thread pool to help with zlib decompression should go a long way here.\n\nProbably too early to think about this, but we'll likely eventually want a global thread pool for doing I\/O and CPU expensive tasks, such as reading chunks from a revlog and decompressing them.\n\nFWIW, we're going to radically alter the storage format in order to better support shallow clones. But that work hasn't started yet. I still think there is a benefit to implementing the revlog code in Rust though.","replyTo":null,"isNewFile":"1","line":"290","lineLength":"3","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"indygreg","id":"43866","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"I would not worry about supporting v0 or v2 at this time. v0 is only important for backwards compatibility with ancient repos. And v2 never got off the ground.","replyTo":null,"isNewFile":"1","line":"95","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"indygreg","id":"43865","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"This is definitely nifty and an impressive achievement \\o\/\n\nThe `r-` commands for testing pure Rust code paths are an interesting idea!\n\nI think I'm OK with including support for this in `hgcli`. But I think the code should live in a separate file so it doesn't pollute `main()`. And it should be behind a Cargo feature flag so we maintain compatibility with `hg` as much as possible by default.\n\nAlso, Mercurial's command line parser is extremely wonky and has some questionable behavior. If the intent is to make `rhg` compatible with `hg`, we would need to preserve this horrible behavior. We'll likely have to write a custom argument parser because of how quirky Mercurial's argument parser is :(","replyTo":null,"isNewFile":"1","line":"233","lineLength":"28","path":"rust\/hgcli\/src\/main.rs","diffId":"6724","author":"indygreg","id":"43864","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"I see this file was copied. There's nothing wrong with that. But does this mean we will need a custom build.rs for each Rust package doing Python? If that's the case, then I would prefer to isolate all our rust-cpython code to a single package, if possible. I'm guessing that could be challenging due to crossing create boundaries. I'm sure there are placed where we don't want to expose symbols outside the crate.\n\nI'm curious how others feel about this.","replyTo":null,"isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hgbase85\/build.rs","diffId":"6724","author":"indygreg","id":"43863","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"comment","comment":"First of all - wow! Thanks for writing all this code. There's definitely a lot to work with. And work with it we will!\n\nThis is definitely too big to review as one commit. If you could do *any* work to split it up, it would be greatly appreciated. I'd focus on the pure Rust pieces first. Everything needed to open revlogs would be great!\n\nYou may find our custom Phabricator extensions (linked from https:\/\/www.mercurial-scm.org\/wiki\/Phabricator) useful for submitting series of commits to Phabricator.\n\nRegarding the performance, that's pretty good! The dirstate code is some of the most optimized code in Mercurial. There are some gnarly Python C hacks to make it fast. Some of those tricks involve using special system calls to walk directories to minimize the number of system calls. I'm not sure if the crate you imported has those optimizations. (I wouldn't be surprised either way.) I wouldn't worry too much about performance at this juncture. But I suspect we could make the Rust code another 50% faster with some tweaking. It would also be interesting to test on a larger repo, say https:\/\/hg.mozilla.org\/mozilla-unified. Also, I believe there are hooks in the dirstate code to use Watchman (fsmonitor). Those hooks are critical in order to achieve peak performance on large repositories.\n\nSince you seem to be proficient at writing lots of Rust code, if you are looking for another project, may I suggest porting `chg` to Rust? That code is in `contrib\/chg`. That might be the easiest component to actually ship in Rust since it is a standalone binary that doesn't link against Python. But we shouldn't get ahead of ourselves :)\n\nAnyway, it is late for me and I need to detach from my computer. I'm sure others will have things to say as well...","author":"indygreg","id":"43862","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"comment","comment":"Hi all,\n\nBased on the discussion a few weeks ago, I come up with a solution for review and discussion. After reading the Oxidation plan, the first thought is to bypass python engine and current plugin system IFF on request. If user (maybe background checker of IDE) request r-* subcommands, then hg gives rust implementations instead of python's. So I try to make hg r-status as fast as possible. The submitted version has comparable performance (as an example of the performance, not evidence, on my MacBook, in hg's own repo, hg r-status 150ms, and hg status 220ms). I am using CodeXL to profile the performance, and plan to use Future.rs to make the loading parallel and maybe 30ms faster.\n\nThe implementation originates from hg python implementation, because the python version is really fast. I tried to split into small changes, however, I eventually to combine all hgstorage module as one commit.\n\nThank you for your comments!","author":"Ivzhh","id":"43861","dateCreated":"1520491361","dateModified":"1520491361"},{"type":"comment","comment":"  - merge with stable\n  - translate base85.c into rust code\n  - move hgbase85 into independent module\n  - add hgstorage crate\n  - hg status implementation in rust\n","author":"Ivzhh","id":"43856","dateCreated":"1520490633","dateModified":"1520490633"},{"type":"update","diffId":"6724","author":"Ivzhh","id":"43855","dateCreated":"1520490633","dateModified":"1520490633"},{"type":"comment","comment":"Thank you @indygreg!\n\nThe OxidationPlan is my best reference when I started to make a move, and this thread is even more helpful. I am really interested in exploring this ;-) In 2014 I was trying to change the hg backend storage to Postgres, a silly and failed experiment.\n\nAnyway, I will save everyone's time and stop talking. I will come back later with a more meaningful implementation.","author":"Ivzhh","id":"34977","dateCreated":"1518075333","dateModified":"1518075333"},{"type":"comment","comment":"To be honest, we're not yet sure what we'll decide for the Python -> Rust bridge. The problem is summarized in the `Rust <=> Python Interop` section on https:\/\/www.mercurial-scm.org\/wiki\/OxidationPlan.\n\nI suspect at some level we'll need a CPython extension for CPython for performance reasons (especially for high volume function calls). PyPy obviously uses CFFI. I think the ideal outcome is we can write Rust that exposes a C API and use CFFI natively on PyPy and something like `cbindgen` + `Milksnake` to auto-generate a CPython extension that acts as a wrapper around the C API exposed by Rust. I'm not sure if anyone has invented this exact wheel yet. If not, it's probably faster to use `rust-cpython`. Maybe several months from now we have enough Rust and maintaining `rust-cpython` is painful enough that we pursue the auto-generated CPython extension route.\n\nWhat I'm trying to say is you have a green field to explore! But at this juncture, perfect is the enemy of done. We'll be happy with any forward progress, even failed experiments.","author":"indygreg","id":"34976","dateCreated":"1518074550","dateModified":"1518074550"},{"type":"comment","comment":"As the author of this patch, actually I have the same concern. I started to translate base85 as baby steps to find a way of integrating rust and cpython, on my side, Today I modify setup.py, policy.py and makefile to run hg's test suit with the new base85. For myself, it is only proof of concept.\n\nMaybe I should take another way: translate more python modules into CFFI-style, and let CFFI call rust implementation. And gradually change more implementations of python modules with corresponding cffi-style, while keep the python interface the same. My own hope is the rust routines will be able to call each other and eventually run some __basic__ tasks without calling python part. And the rust still lazily provides info to python interface for extensions etc.\n\nI am exploring this way now, and hope the findings will be useful for community to make decision.\n\nThank you all for the comments!","author":"Ivzhh","id":"34975","dateCreated":"1518070365","dateModified":"1518070365"},{"type":"comment","comment":"What would be the advantage of taking this? Since we already have the C implementation, it's not likely to gain us any performance. On the other hand, it might make a good test case for integrating Rust and Python, finding the right API boundaries and experimenting with different approaches, precisely \/\/because\/\/ we already have a C implementation. @indygreg @durin42 what are your thoughts about it?\n\n","author":"krbullock","id":"34910","dateCreated":"1518062354","dateModified":"1518062354"},{"type":"comment","comment":"I agree with the splitting comments :) In fact there might already be a base85 crate which can be used: https:\/\/docs.rs\/zero85. Either way I'll hold off on the review, feel free to ping me when you are ready for me to take a look.","author":"kevincox","id":"34640","dateCreated":"1518001891","dateModified":"1518001891"},{"type":"comment","comment":"Thank you @indygreg for your detailed explanation!\n\nI understand the process now, and I will go back reading the developer's guide thoroughly again. I will try my best to provide a relatively clean stack of patches.\n\nThank you for you time!","author":"Ivzhh","id":"34561","dateCreated":"1517972031","dateModified":"1517972031"},{"type":"comment","comment":"We generally prefer that patches to Mercurial be small and do a single thing. This makes it easier to review and understand changes, since each change can be evaluated in isolation. If you submit changesets together using `hg phabsend`, they automatically show up as a \/\/stack\/\/ in Phabricator. And if changesets at the bottom of the stack are ready to land, we generally land those without waiting for the entire stack to land. This enables forward progress to be made and this is generally better for everyone than waiting until a series of commits is perfect before adding any of them.\n\nWhat that means is you should ideally split this work into smaller parts. For example:\n\n  # Add the pure Rust code\/crate\n  # Add the Python Rust code\/crate\n  # Build system \/ module policy changes\n\nI'm not sure of the order of things though. Since this is the first Rust extension, it's not clear what needs to be implemented in what order. I'm fine looking at a large commit if things are too tightly coupled to separate. But you should strive to make smaller commits.\n\n","author":"indygreg","id":"34557","dateCreated":"1517970792","dateModified":"1517970792"},{"type":"comment","comment":"Sure, thank you for the comments! I can definitely prepare makefile and setup.py to make the building process work with rust part. I am planning to change the policy.py module to support and try to load rust modules and run all the tests. I will submit a new patch after finishing these two tasks.\n\nAfter reading wiki\/OxidationPlan again, I plan to change to cffi for better compatibility (pypy and others), and try to build algorithms in pure rust. Shall I wait till migrating to cffi based solution now and resubmit this patch with all three changes (building, testing, and cffi)?\n\nThank you!","author":"Ivzhh","id":"34556","dateCreated":"1517970271","dateModified":"1517970271"},{"type":"comment","comment":"Yes, we should definitely split things into multiple crates. Small, narrowly-focused crates does seem to be the Rust way, after all.\n\n`hgcli` should be for things specific to the Rust implementation of `hg`. I think this can also include the feature set of `chg` (once we've ported `chg` to Rust).\n\nI definitely support separating the \"pure Rust\" from the \"Python Rust\" via a crate boundary. It is generally useful to have Rust that isn't bound to Python because it will facilitate reuse outside of Python contexts. For example, someone could implement a Mercurial wire protocol server in pure Rust without needing to worry about Python. Of course, we're likely to encounter areas where we really want tight coupling in order to achieve optimal performance in Python. So we may have to design APIs on the pure Rust side to facilitate CPython use. I'm OK with that.\n\nAs for how many crates to have, I don't have super strong opinions. I could see us putting every little component\/subsystem in its own crate. I could also see us putting everything in one large crate. I don't think it is worth deciding at this early juncture. API design and ability to be reused outside its originally intended purpose is the important property to strive for. I think that has more to do with how the code is authored rather than which crates things are in.\n\nA missing piece of this patch is the build system and module loader integration. We have a \/\/module policy\/\/ that dictates which implementation of a Python module we use. We probably want to introduce a `rust` policy that uses Rust-based modules where available and falls back to the `cext` modules\/policy if a Rust module isn't available. We also need to figure out how to integrate Rust into `setup.py`. But I think the build system bit can be deferred until we're actually ready to ship Rust, which is still a bit of ways off. I'm happy for the workflow to be \/\/run cargo in order to load Rust modules\/\/ for the time being. But if you can implement `Makefile` and\/or `setup.py` integration to build these Rust extensions, that would be awesome.","author":"indygreg","id":"34484","dateCreated":"1517947275","dateModified":"1517947275"},{"type":"comment","comment":"I am open to the three-crates plan. Oirginally I have hgcli and hgext separately, and I was planning to use CFFI mode. I am a pypy user too, so I will be willing to provide a python C API free crate for pypy and others.","author":"Ivzhh","id":"34443","dateCreated":"1517928889","dateModified":"1517944524"},{"type":"inline","comment":"I think I'd like to separate things a bit more and have a Python-free module, and then a glue module that we can use to call into the pure Rust. Part of the reason is that in my perfect world we won't use the cpython crate for speedups so they can be used from pypy as well. Separating them at least makes it easier to have an extern \"C\" version of the method that can be used from cffi instead of only through the CPython API.\n\n(Not sure what opinions others have. It's likely that I'll attempt this approach in the near future as part of a continued attempt to speed up `hg diff`.)","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"rust\/hgcli\/src\/hgext\/base85.rs","diffId":"5238","author":"durin42","id":"34390","dateCreated":"1517913293","dateModified":"1517913293"},{"type":"comment","comment":"I'd be curious to see what @indygreg has to say about this, maybe wait on his input before doing any work in response to my feedback?\n\nI do wonder if we should have at least three crates:\n\n # hgcli\n # libmercurial\n # hgcext\n\nThe first one would be the command-line entry point, the last could use the cpython API, and libmercurial would be \"pure rust\" and open the door to eventually having a libhg or something that exports C functions and would be suitable for cffi and linking into other binaries?","author":"durin42","id":"34389","dateCreated":"1517913293","dateModified":"1517913293"},{"type":"update","diffId":"5238","author":"Ivzhh","id":"34367","dateCreated":"1517869861","dateModified":"1517869861"}],"dateCreated":"1517869861","dateModified":"1579887188","status":"Needs Revision"},{"id":"2623","callsign":"HG","title":"dispatch: adding config items for overriding flag defaults","author":"rdamazio","summary":"This introduces the new defaults format \"commandname.default.optionname\" which\ndirectly overrides the default of the option, instead of prepending the\ncommand-line option. This is meant to replace the [defaults] section which is\nalready deprecated in a manner that's easier and safer to use than creating\naliases.","testPlan":"","lineCount":"96","dependsOn":["2622"],"reviewers":["yuja","baymax"],"ccs":["dploch","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117697","dateCreated":"1579887186","dateModified":"1579887186"},{"type":"reject","author":"baymax","id":"117696","dateCreated":"1579887186","dateModified":"1579887186"},{"type":"inline","comment":"I thought callables were meant to be used to generate the default default, not with overridden values?","replyTo":"43409","isNewFile":"1","line":"625","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"rdamazio","id":"47743","dateCreated":"1522132208","dateModified":"1522132208"},{"type":"inline","comment":"Nobody should use the same *instance* on multiple flags. Even with the current flags, if you use e.g. the same list on many, that'll cause problems with listopt.\n","replyTo":"43410","isNewFile":"1","line":"639","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"rdamazio","id":"47742","dateCreated":"1522132208","dateModified":"1522132208"},{"type":"inline","comment":"This makes me nervous.  What if someone re-uses a customopt instance in multiple commands?  i.e.:\n\nDATE_FLAG = mypkg.dateopt()\n...\n('b', 'before', DATE_FLAG, '')\n('a', 'after', 'DATE_FLAG', '')\n\nNow, setting commands.defaults.before=2018-03-05 also silently changes the default for 'after'.  I suspect we need to introduce a wrapper class like what I suggest on lines 625-625, that delegates and leaves the original default unchanged.  And either way, we should probably clarify in the docs on customopts what expected use of the class is (i.e., should we just forbid reuse, is 'oldstate' safe to mutate, etc.)","replyTo":null,"isNewFile":"1","line":"639","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"dploch","id":"43410","dateCreated":"1520292544","dateModified":"1520292544"},{"type":"inline","comment":"This doesn't handle callables properly.  I wonder if the something like the following would work instead:\n\noldopt = fancyopts._defaultopt(olddefault)\nnewdefault = old.opt.newstate(olddefault, ui.config(\"commands\", cfgitem)\nc[idx] = (opt[0], opt[1], fancyopts._withnewdefault(oldopt, newdefault), opt[3])\n\nWhere '_withnewdefault' is a wrapper customopt that just changes the default.","replyTo":null,"isNewFile":"1","line":"625","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"dploch","id":"43409","dateCreated":"1520292544","dateModified":"1520292544"},{"type":"inline","comment":"I think rdamazio's response is correct.  The type information for an opt exists only in the 'defaultvalue' slot in the tuple, so it needs to be extracted from there before reading the config.  I don't have a strong opinion as to where this code should go - 'ui' does seem marginally more appropriate than 'fancyopts', since it keeps 'fancyopts' low-level and not depending on 'ui'.","replyTo":"42582","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"dploch","id":"43408","dateCreated":"1520292544","dateModified":"1520292544"},{"type":"inline","comment":"Ah, makes sense. See if this addresses that case satisfactorily - it still has the caveat of not being able to \"reset\" container types, but that's true of the command line as well (if you have a list flag with a non-empty default, there's no way to remove that default item).","replyTo":"42770","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"rdamazio","id":"43071","dateCreated":"1520195950","dateModified":"1520195950"},{"type":"update","diffId":"6609","author":"rdamazio","id":"43064","dateCreated":"1520195818","dateModified":"1520195818"},{"type":"inline","comment":"IIUC, an extension author may implement its own customopt subclasses, and\nput them into the command table, so we can't make ui.configtyped to\nsupport all of them.","replyTo":"42686","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"yuja","id":"42770","dateCreated":"1520183736","dateModified":"1520183736"},{"type":"inline","comment":"You're right, I had the plain logic inverted in my head. Removed.","replyTo":"42581","isNewFile":"1","line":"390","lineLength":"0","path":"mercurial\/ui.py","diffId":"6523","author":"rdamazio","id":"42687","dateCreated":"1520181261","dateModified":"1520181261"},{"type":"inline","comment":"The issue is that customopt (and all its children) assume the value type is already the correct one, and thus do not perform any conversion. Since we're parsing values from the config file, the conversion is desired to ensure they don't all end up as text - the config{bool,int,etc} methods called by configtyped perform the proper conversion. In most cases (all commands that declare default values) no conversio is needed since those already have the correct type.\n","replyTo":"42582","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"rdamazio","id":"42686","dateCreated":"1520181261","dateModified":"1520181261"},{"type":"update","diffId":"6548","author":"rdamazio","id":"42684","dateCreated":"1520181250","dateModified":"1520181250"},{"type":"inline","comment":"Maybe this type conversion can be a `fancyopt.customopt` method since we've\nrefactored the default handling by D2090?\n\n```\n# no idea if _defaultopt() should be made public or the whole commands.default handling\n# should be moved to fancyopts\nx = fancyopts._defaultopt(olddefault)\nnewdefault = x.configdefault(ui, cmd, optname, ...)\n```\n\n@dploch, any suggestions?","replyTo":null,"isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"yuja","id":"42582","dateCreated":"1520173297","dateModified":"1520173297"},{"type":"inline","comment":"Perhaps this is noop since `[commands]` is removed at all if `ui.plain()` returns True.","replyTo":null,"isNewFile":"1","line":"390","lineLength":"0","path":"mercurial\/ui.py","diffId":"6523","author":"yuja","id":"42581","dateCreated":"1520173297","dateModified":"1520173297"},{"type":"reject","author":"yuja","id":"42578","dateCreated":"1520173297","dateModified":"1520173297"},{"type":"comment","comment":"FYI this is a change I had previously sent to the list as 60b3222e01f96f91ece7eda9681a89bf3bb930a6, and Yuya reviewed . I just had never followed up on it.","author":"rdamazio","id":"42436","dateCreated":"1520122245","dateModified":"1520122245"},{"type":"update","diffId":"6523","author":"rdamazio","id":"42435","dateCreated":"1520121514","dateModified":"1520121514"},{"type":"update","diffId":"6521","author":"rdamazio","id":"42421","dateCreated":"1520121282","dateModified":"1520121282"}],"dateCreated":"1520121282","dateModified":"1579887186","status":"Needs Revision"},{"id":"3663","callsign":"HG","title":"graft: add test showing --continue not preserving --edit passed earlier","author":"pulkit","summary":"Right now, if you run `hg graft --edit`, face some conflicts, resolve them and\nthen run `hg graft --continue`, you will see graft no longer pops up for the\neditor and you hate mercurial for not remembering arguments you passed earlier.\n\nUpcoming patch will fix this buggy behavior and this test will help us in\nrealizing those changes.","testPlan":"","lineCount":"41","dependsOn":[],"reviewers":["baymax"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117694","dateCreated":"1579887185","dateModified":"1579887185"},{"type":"reject","author":"baymax","id":"117693","dateCreated":"1579887185","dateModified":"1579887185"},{"type":"update","diffId":"8908","author":"pulkit","id":"57562","dateCreated":"1527287120","dateModified":"1527287120"}],"dateCreated":"1527287120","dateModified":"1579887185","status":"Needs Revision"},{"id":"3187","callsign":"HG","title":"phase: add dry-run functionality","author":"khanchi97","summary":"Added the logic to find those csets whose phase will be changed\n(while running without --dry-run). And show the list of those csets.","testPlan":"","lineCount":"173","dependsOn":[],"reviewers":["pulkit","baymax"],"ccs":["av6","mercurial-devel"],"actions":[{"type":"comment","comment":"There seems to have been no activities on this Diff for the past 3 Months.\n\nBy policy, we are automatically moving it out of the `need-review` state.\n\nPlease, move it back to `need-review` without hesitation if this diff should still be discussed.\n\n:baymax:need-review-idle:\n","author":"baymax","id":"117691","dateCreated":"1579887184","dateModified":"1579887184"},{"type":"reject","author":"baymax","id":"117690","dateCreated":"1579887184","dateModified":"1579887184"},{"type":"update","diffId":"8962","author":"khanchi97","id":"57894","dateCreated":"1528037274","dateModified":"1528037274"},{"type":"comment","comment":"Nice work! I like where how you simplified things from previous version.\n\nIf you look at the patch, this seems to do multiple things at once which are:\n\n  * adding dry-run argument to advanceboundary and retractboundary functions\n  * adding a new --dry-run flag to hg phase\n\nLet's break things up in individual patches so that we can improve more on individual pieces. Can you split this into a separate patch for adding dryrun argument to each function, i.e. one patch for adcanceboundary, one for retractboundary, and then one last patch which adds the new flag? That will be very much helpful in reviewing this work and also making incremental changes and moving forward step by step.","author":"pulkit","id":"57621","dateCreated":"1527622549","dateModified":"1527622549"},{"type":"comment","comment":"@pulkit Now I moved the logic for finding revs (those phase will change)  to advanceboundry and retractboundry function and for now it shows all nodes. I am working to show range instead. Take a look at this when you are free :)","author":"khanchi97","id":"57619","dateCreated":"1527584154","dateModified":"1527584154"},{"type":"update","diffId":"8896","author":"khanchi97","id":"57476","dateCreated":"1527280427","dateModified":"1527280427"},{"type":"comment","comment":">>! In D3187#57349, @khanchi97 wrote:\n> okay, but I have some queries like\n> 1. How about showing revision no. instead of cset id?\n\nI think we should show cset ids. If you want to with rev numbers, go with that. This should not be a blocker to get the initial patch in.\n> 2. And in this https:\/\/pastebin.com\/raw\/kWcr9xVK example if I change revision 2 phase to --secret then how it should print the range, I mean now we have branches in this range?\n> \n> Can we show that range like this:\n> \n> 0316ce92851d : : b385d13d5ed4  draft  ->  secret\n> 0316ce92851d : : 4ccc844d5454   draft  -> secret\n\nThere are two ways you can show the range in this case:\n\n1) 0316ce92851d::b385d13d5ed4 and f19b7f89f44e::4ccc844d5454\n2) 0316ce92851d::4ccc844d5454 and b385d13d5ed4\n\nLook into `hg help revsets` to understand what `::` means.","author":"pulkit","id":"57419","dateCreated":"1527196739","dateModified":"1527196739"},{"type":"comment","comment":"okay, but I have some queries like\n1. How about showing revision no. instead of cset id?\n2. And in this https:\/\/pastebin.com\/raw\/kWcr9xVK example if I change revision 2 phase to --secret then how it should print the range, I mean now we have branches in this range?\n\nCan we show that range like this:\n\n0316ce92851d : : b385d13d5ed4  draft  ->  secret\n0316ce92851d : : 4ccc844d5454   draft  -> secret","author":"khanchi97","id":"57349","dateCreated":"1527158527","dateModified":"1527158527"},{"type":"inline","comment":"This is not very much helpful. In such cases, how about showing the range of changesets, something like:\n```f7b1eb17ad24::925d80f479bb public -> draft\nb385d13d5ed4::fdc0253c25cf secret -> draft``` ","replyTo":null,"isNewFile":"1","line":"990","lineLength":"0","path":"tests\/test-phases.t","diffId":"7877","author":"pulkit","id":"57180","dateCreated":"1526844970","dateModified":"1526844970"},{"type":"inline","comment":"Since all the logic is copy-pasted from phases.advanceboundary and phases.retractboundary, why not we just pass the `--dry-run` option there and get the count from those functions only.","replyTo":null,"isNewFile":"1","line":"3898","lineLength":"0","path":"mercurial\/commands.py","diffId":"7877","author":"pulkit","id":"57179","dateCreated":"1526844970","dateModified":"1526844970"},{"type":"comment","comment":"@pulkit Can you please review it?","author":"khanchi97","id":"51519","dateCreated":"1523353338","dateModified":"1523353338"},{"type":"update","diffId":"7877","author":"khanchi97","id":"51174","dateCreated":"1523185235","dateModified":"1523185235"},{"type":"inline","comment":"`\"cannot use --dry-run without target phase\"`","replyTo":null,"isNewFile":"1","line":"3872","lineLength":"0","path":"mercurial\/commands.py","diffId":"7874","author":"av6","id":"51173","dateCreated":"1523167056","dateModified":"1523167056"},{"type":"update","diffId":"7874","author&q