hgweb: don't call sys.exit() in httpservice.run() If I'm reading the code correctly, `mercurial.server.createservice()` can return an hgweb service or one of three types of command server services. The caller then calls `mercurial.server.runservice()`, passing it the returned service's run method. Only the hgweb service was calling `sys.exit()`. It has been that way since 8d44649df03b (refactor ssh server., 2006-06-04). That commit message doesn't provide any explanation. Let's clean up and have the code follow the usual return path into the `dispatch` module. After this patch, there should be no remaining places left where we call `sys.exit()` except for valid uses in the `dispatch` and `worker` modules. Differential Revision: https://phab.mercurial-scm.org/D9272

serve: simply return instead of calling sys.exit() in `hg serve --stdio` The shouldn't be a reason to call `sys.exit()` instead of letting the code return normally. I've remove the call in both `hg serve` and `hg debugserve`. Differential Revision: https://phab.mercurial-scm.org/D9271

httpservice: move sys.exit() out of serve_forever() This is a simple refactoring to show the callers of the method, so it's easier to reason about the impact of removing the `sys.exit()` calls in subsequent patches. Differential Revision: https://phab.mercurial-scm.org/D9270

copies: handle more cases where a file got replaced by a copy This patch fixes the changeset-centric version in a pretty straight-forward way. It fixes it to automatically resolve the conflict, which is better than resulting in a modify/delete conflict as it was before b4057d001760 (merge: when rename was made on both sides, use ancestor as merge base, 2020-01-22). I'll leave it for later to test and explicitly handle cases where files have been renamed to the same target on different sides of the merge. Differential Revision: https://phab.mercurial-scm.org/D8653

tests: test more cases where a file got replaced by a copy This adds a test where a file is modified on one branch and is renamed onto another file in another branch. That should ideally be automatically resolved (by propagating the modification to the rename destination). Alternatively, it could be considered a modify/delete conflict. It should at least not be automatically resolved by ignoring the modification. However, that is what actually happens with the changeset-centric algorithm since I broke it in b4057d001760 (merge: when rename was made on both sides, use ancestor as merge base, 2020-01-22). Before that commit, it resulted in a modify/delete conflict. The filelog-centric algorithm was broken already before that commit. Differential Revision: https://phab.mercurial-scm.org/D8652

unionrepo: don't insert index tuples with None as int field None is not a valid size. Use -1 as placeholder instead. This will be necessary when the index starts enforcing type correctness. Differential Revision: https://phab.mercurial-scm.org/D9161

bundlerepo: don't insert index tuples with full nodes as linkrev The index format has a documented format and latter changes will start to enforce the field types. The bundlerepo uses full nodes for the linkrev field when it should be using revision numbers. Use the link mapping to resolve them, except in the special case of self-references. Those are actually indications of a missing linkrev. Differential Revision: https://phab.mercurial-scm.org/D9160