context: switch ctx() use to changectx() I added `ctx()` to `overlayworkingfilectx`, (and before that, `absentfilectx`), because `absentfilectx` had reference to this function in its `cmp()` function. But the standard is actually `changectx()`, and no other class implements `ctx()`. So let's use the standard name. (As a result, I'm not sure that part of the `absentfilectx` comparator ever worked! It was written before I added either function.) This will be necessary in the next patch. Differential Revision: https://phab.mercurial-scm.org/D1211

lfs: introduce a user level cache for lfs files This is the same mechanism in place for largefiles, and solves several problems working with multiple local repositories. The existing largefiles method is reused in place, because I suspect that there are other functions that can be shared. If we wait a bit to identify more before `hg cp lfutil.py ...`, the history will be easier to trace. The push between repo14 and repo15 in test-lfs.t arguably shouldn't be uploading any files with a local push. Maybe we can revisit that when `hg push` without 'lfs.url' can upload files to the push destination. Then it would be consistent for blobs in a local push to be linked to the local destination's cache. The cache property is added to run-tests.py, the same as the largefiles property, so that test generated files don't pollute the real location. Having files available locally broke a couple existing lfs-test-server tests, so the cache is cleared in a few places to force file download.

largefiles: refactor _usercachedir() to allow reuse with lfs Largefiles puts everything into a flat directory, while lfs divides files up by creating subdirectories consisting of the first two characters of the hash. Therefore, pointing at the largefiles cache won't work.

lfs-test: note a problem with unpushed lfs files and cloning/sharing AFAIK, this isn't an issue with largefiles because it knows how to look in the system-wide cache.

patch: add within-line color diff capacity The `diff' command usually writes deletion in red and insertions in green. This patch adds within-line colors, to highlight which part of the lines differ. Lines to compare are decided based on their similarity ratio, as computed by difflib SequenceMatcher, with an arbitrary threshold (0.7) to decide at which point two lines are considered entirely different (therefore no inline-diff required). The current implementation is kept behind an experimental flag in order to test the effect on performance. In order to activate it, set inline-color-diff to true in [experimental].

dagop: extend filectxancestors() to walk multiple files

dagop: put start fctx into visit dict of filectxancestors() Prepares for multiple start revisions/files.

dagop: change visit dict of filectxancestors() indexed solely by rev In future patches, a max heap will be used to compute the next revision to visit.

dagop: use fctx.rev() consistently in filectxancestors() We can't use fctx.linkrev() to sort fctxs coming from multiple files. This was changed at 24b57c3899f8 due to performance issue, but we know we evaluate parent.rev() in revset anyway.

dagop: yield intro filectx by filectxancestors() This is the convention of dagop.*ancestors() functions.

filectx: extract helper method to obtain filectx pointing to its introrev

dagop: copy basefilectx.ancestors() to free function The primary goal of this series is to make follow() support multiple start revisions. dagop.filectxancestors() will be extended to take multiple filectxs. basefilectx.ancestors() is not forwarded to this function because doing that would resurrect the performance issue fixed by 24b57c3899f8.

test-log: test that fctx.ancestors() can't index parents only by linkrev This covers a possible bug that could be caused by the following change: --- a/mercurial/context.py +++ b/mercurial/context.py @@ -1047,7 +1047,7 @@ class basefilectx(object): while True: for parent in c.parents()[:cut]: - visit[(parent.linkrev(), parent.filenode())] = parent + visit[parent.linkrev()] = parent if not visit: break c = visit.pop(max(visit))

pull: retrieve bookmarks through the binary part when possible This makes pull consistent with the part used by push and provide us with a more compact representation of bookmarks. In addition, this opens the way for smarter bookmark exchanges (e.g. filtering by names or only sending the bookmark relevant to the pulled set, etc).

getbundle: add support for 'bookmarks' boolean argument This new argument requests a 'bookmarks' part from the server. It is meant to be used instead of the "listkeys" request.

bundle2: support a 'records' mode for the 'bookmarks' part In this mode, the bookmarks changes are record in the 'bundleoperation' records instead of inflicted to the repository. This is necessary to use the part when pulling.

bundle2: add a 'modes' dictionary to the bundle operation This new attribute allows the codes requesting an unbundling to pass important information to individual part handlers. The current target use case is to allow for receiving 'bookmarks' part without directly updating local repository, but just recording the received data instead. This is necessary for pull where the remote bookmarks are processed locally. I expect the concept to be beneficial to other parts in the future. To clarify the bookmark behavior on pull, the remote bookmark value are not just taken -as-is- into the local repository. There is an extra step to detect bookmark divergence. The remote bookmarks data are stored until this processing happens.

bookmark: use the 'bookmarks' bundle2 part to push bookmark update (issue5165) We use the new binary parts we introduced earlier to exchange bookmark. The payload is a bit more compact since we use binary and the length of bookmarks is no longer constrained to 255. .. fix:: Issue 5165 Bookmark, whose name is longer than 255, can again be exchanged again between 4.4+ client and servers.

bookmark: introduce in advance a variant of the exchange test We are about to introduce a new way to push bookmark to server. We introduce the test variant before actually updating the exchange to help the output changes to stand out when it happens.

push: move bundle2-pushkey based bookmarks exchange in its own function We are about to introduce an alternative way to push bookmark over bundle2.

bookmark: add pushkey hook compatiblity to the bundle2 part Currently, pushing a bookmark update triggers a pushkey hooks. It is likely that users in the wild use such hooks to control bookmark movement. Using a non push-key mechanism to exchange bookmark means these hooks are no longer called, possibly breaking existing users setup. So we add explicit call to the pushkey hooks in the handling of the bundle2 part. This behavior can be disabled with a new config knob: 'server.bookmarks-pushkey-compat'.

bookmark: introduce a 'bookmarks' part This part can carry and apply bookmarks information. We start with adding the core behavior of the part. In its current form, the part is only suitable for push since it plain update the bookmark without consideration for the local state. Support of the behavior needed for pulling will be added in later changesets.

push: include a 'check:bookmarks' part when possible Before updating the actual bookmark update, we can start with updating the way we check for push race. Checking bookmarks state earlier is useful even if we still use pushkey. Aborting before the changegroup is added can save a lot of time.

bookmark: add a 'check:bookmarks' bundle2 part This part checks that bookmarks are still at the node they are expected to be. This allows a pushing client to detect push race where the repository was updated between the time it discovered the server state and the time it managed to finish its push. Such checking already exists when pushing bookmark through pushkey. This new part can be inserted at the beginning of the bundle, triggering abort earlier. In addition, we would like to move away from pushey to push bookmark. A step useful to solve issue5165.

bookmark: add methods to binary encode and decode bookmark values Coming new bundle2 parts related to bookmark will use a binary encoding. It encodes a series of '(bookmark, node)' pairs. Bookmark name has a high enough size limit to not be affected by issue5165. (64K length, we are well covered)

tests: remove {a..h} bashism from remotenames I'm not bothering with a check-code test because this is a weird construct that I didn't even know existed before it was breaking the BSD build, and it also appears to fail if /bin/sh is dash like it is on our Linux builder. Differential Revision: https://phab.mercurial-scm.org/D1605

hgweb: move common vertex code to Graph.prototype Just to give some context to the return values: vertex() needs to return two HTML elements as strings, <li> to be used as a background and a <li> to be shown in foreground. The latter was made obsolete recently when changesets started to be rendered server-side, but background elements are still useful for now.

hgweb: create Graph methods using a prototype This way it's possible to call the original methods even if they were overridden.

hgweb: remove unused Graph.cur property It was introduced in 0dba955c2636, but was already unused. I missed it in e46f0b653002.

tests: remove shell function helper from test-largefiles-misc Now that all the complexity is in a Python script, we can just directly invoke the tool. Differential Revision: https://phab.mercurial-scm.org/D1599

contrib: ban find(1)'s -printf operator, as it is a GNU-ism Differential Revision: https://phab.mercurial-scm.org/D1598

merge with stable

repoview: include filter name in repr for debugging

repoview: extract a factory function of proxy class This makes sure that dynamically-created class objects are isolated from local binding of repo instances. The type cache is moved to module level as it isn't tied to each instance.

repoview: do not include filter name in name of proxy class The type object is shared across all filters. I'll add __repr__() instead.

setup: convert version strings to unicode on Python 3 Fixes the following error: stderr from 'hg log -T x -r only(.,'b'4.4.2'')': b' hg: parse error at 10: unexpected token: symbol'

thirdparty: move selectors2 module to where it should be

rewriteutil: use precheck() in uncommit and amend commands Differential Revision: https://phab.mercurial-scm.org/D1526

rewriteutil: add a precheck function to check if revs can be rewritten The precheck function is intended to be used before we start rewritting changesets. Differential Revision: https://phab.mercurial-scm.org/D1503

rewriteutil: add utility function to check if we can create new unstable cset This patch adds a new file which will contain utility functions related to rewritting changesets. It also adds a utility function to check if the rewritting operation creates new unstable changesets and are we allowed to create them. This rewriteutil.py introduced in this patch and the utility functions added in the upcoming patches exists in the evolve extension are being ported from there. Differential Revision: https://phab.mercurial-scm.org/D1502

test-run-tests: do not rebuild hg in the test d600bda4 and fc0f3ed0 added code to call `$PYTHON run-tests.py ...`. That will rebuild hg, is slow and could have other crashes from setup.py, like: Unable to find a working hg binary to extract the version from the repository tags Therefore use `run-tests.py -l` instead. Differential Revision: https://phab.mercurial-scm.org/D1595

remotenames: consider existing data while storing newer data Previously reviewed as D1357. Differential Revision: https://phab.mercurial-scm.org/D1551

remotenames: add functions to read remotenames data from .hg/remotenames/ This patch functions which can be used to read remotenames data from .hg/remotenames/. The logic for the function which reads the remotenames file is taken from the remotenames extension. Previously reviewed as D940. Differential Revision: https://phab.mercurial-scm.org/D1550

remotenames: add test showing overwriting on remotenames data The current storage logic every time overwrites the existing data with the new data. This patch adds test to demonstrate that. To fix this, we need to add logic to read existing remotenames data and merge with existing data which will be added in upcoming changesets. Previously reviewed as D1356. Differential Revision: https://phab.mercurial-scm.org/D1549

remotenames: add functionality to store remotenames under .hg/hgremotenames/ This patch moves the functionality from remotenames extension to store remotenames to core. Storage format used by remotenames extension: A single file `.hg/remotenames` with an entry in each line where each line is of format: `node nametype remotepath/name` where nametype is either 'bookmarks' or 'branches'. This was not the best way to store data, so while moving to core the storage format was changed but yet not the final format. The storage format used by core after this patch will be: * A file for each type of name i.e. bookmarks and branches in .hg/remotenames/ directory * A version number on the top of the file. The version for current format is 0. * An entry in each line where each line is of the format `node\0remotepath\0name` The logic to sync with existing remotenames file and saving journals and other related things will be moved to core in next patches incrementally. Thanks to Ryan, Augie and Durham for suggestions on storage format. Previously reviewed as D939. Differential Revision: https://phab.mercurial-scm.org/D1548

remotenames: move function to pull remotenames from the remoterepo to core This patch is the first patch of the series moving functionality from hgremotenames extension to core. There are lot of functionality in the extension which in the end enables us to store branch heads and bookmarks location on a server from which we are pulling or cloning from. This will help us in creating a better bookmark workflow where we can show user that a certain server has this bookmarks at this node. It will also introduce namespaces related to remote bookmarks and remote branches. This patch moves the functionality to pull branches and bookmarks from a server from which we are pulling to core behind config option `experimental.remotenames`. This patch adds a test which helps us to analyse whether things are working or not. We are currently writing things to ui, we will write information to files in upcoming patches. Previously reviewed as D937. Differential Revision: https://phab.mercurial-scm.org/D1547

test: fix bad replace for fixing pure-only build When we replaced the patterns, glob was removed on the fixed line, it was a mistake and caused the pure-only build to fails. Differential Revision: https://phab.mercurial-scm.org/D1592

test: fix common-pattern for pure variant The $USUAL_COMPRESSIONS$ value that was taken was not compatible with the pure variant systems as zlib seems to not be available in these case. Differential Revision: https://phab.mercurial-scm.org/D1562

tests: add a substitution for EADDRINUSE/WSAEADDRINUSE messages I suspect some more of these are globbed out, so this is a bit of future proofing.

tests: add a substitution for ECONNRESET/WSAECONNRESET messages

tests: add a substitution for ENOTDIR/ERROR_PATH_NOT_FOUND messages

tests: add a substitution for ENOENT/ERROR_FILE_NOT_FOUND messages Automatic replacement seems better than trying to figure out a check-code rule. I didn't bother looking to see why the error message and file name is reversed in the annotate and histedit tests, based on Windows or not. I originally had this as a list of tuples, conditional on the platform. But there are a couple of 'No such file or directory' messages emitted by Mercurial itself, so unconditional is required for stability. There are also several variants of what I assume is 'connection refused' and 'unknown host' in test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc. Yes, these are handled by (re) tags, but maybe it would be better to capture those strings in order to avoid whack-a-mole in future tests. All of this points to using a dictionary containing one or more strings-to-be-replaced values.

setup: only write some autogenerated files if they change Without this change, setup.py always writes some files on every invocation. This prevents some builds from being a no-op when they should. And, since times can sneak into generated .pyc files, this prevents file content from being deterministic between builds. As part of the refactor, we treat file content as bytes. The only potential regression from this would be if some tool is looking at mtimes of the changed files to determine if further action should be taken. But I don't think anything critically important is keyed off the mtimes of these specific files. Differential Revision: https://phab.mercurial-scm.org/D1580

python3: whitelist many more passing tests Differential Revision: https://phab.mercurial-scm.org/D1584

fancyopts: fix handling of "--" value in earlygetopt()

fancyopts: use getopt.gnu_getopt() The issue described in the docstring has been fixed since Python 20ab2260dc93, which is in 2.7. https://hg.python.org/cpython/rev/20ab2260dc93 https://bugs.python.org/issue4458 This fixes the handling of '--' value.

dispatch: replace _earlygetopt(strip=True) with new parser The execution order in cmdalias.__init__() is adjusted to set stripped args to self.givenargs, which is no longer updated in place.

dispatch: replace _earlyreq*() with new fancyopts-based parser

dispatch: alias --repo to --repository while parsing early options This prepares for replacing old _early*opt() functions. My initial attempt was to extend options table to support 'repository|repo' syntax. It worked, but seemed too invasive. So I decided to add an optional argument to fancyopts() instead. This also changes the nevernegate dict to be keyed by a canonical_name, not by an option-name for clarity.

spartan: render changesets server-side on /graph page

monoblue: render changesets server-side on /graph page

gitweb: render changesets server-side on /graph page

paper: render changesets server-side on /graph page

hgweb: only include graph-related data in jsdata variable on /graph pages (BC) Historically, client-side graph code was not only rendering the graph itself, but it was also adding all of the changeset information to the page as well. It meant that JavaScript code needed to construct valid HTML as a string (although proper escaping was done server-side). It wasn't too clunky, even though it meant that a lot of server-side things were duplicated client-side for no good reason, but the worst thing about it was the data format it used. It was somewhat future-proof, but not human-friendly, because it was just a tuple: it was possible to append things to it (as was done in e.g. 270f57d35525), but you'd then have to remember the indices and reading the resulting JS code wasn't easy, because cur[8] is not descriptive at all. So what would need to happen for graph to have more features, such as more changeset information or a different vertex style (branch-closing, obsolete)? First you'd need to take some property, process it (e.g. escape and pass through templatefilters function, and mind the encoding too), append it to jsdata and remember its index, then go add nearly identical JavaScript code to 4 different hgweb themes that use jsdata to render HTML, and finally try and forget how brittle it all felt. Oh yeah, and the indices go to double digits if we add 2 more items, say phase and obsolescence, and there are more to come. Rendering vertex in a different style would need another property (say, character "o", "_", or "x"), except if you want to be backwards-compatible, it would need to go after tags and bookmarks, and that just doesn't feel right. So here I'm trying to fix both the duplication of code and the data format: - changesets will be rendered by hgweb templates the same way as changelog and other such pages, so jsdata won't need any information that's not needed for rendering the graph itself - jsdata will be a dict, or an Object in JS, which is a lot nicer to humans and is a lot more future-proof in the long run, because it doesn't use numeric indices What about hgweb themes? Obviously, this will break all hgweb themes that render graph in JavaScript, including 3rd-party custom ones. But this will also reduce the size of client-side code and make it more uniform, so that it can be shared across hgweb themes, further reducing its size. The next few patches demonstrate that it's not hard to adapt a theme to these changes. And in a later series, I'm planning to move duplicate JS code from */graph.tmpl to mercurial.js and leave only 4 lines of code embedded in those <script> elements, and even that would be just to allow redefining graph.vertex function. So adapting a custom 3rd-party theme to these changes would mean: - creating or copying graphnode.tmpl and adding it to the map file (if a theme doesn't already use __base__) - modifying one line in graph.tmpl and simply removing the bigger part of JavaScript code from there Making these changes in this patch and not updating every hgweb theme that uses jsdata at the same time is a bit of a cheat to make this series more manageable: /graph pages that use jsdata are broken by this patch, but since there are no tests that would detect this, bisect works fine; and themes are updated separately, in the next 4 patches of this series to ease reviewing.