The same applies to '?' if --quiet is used (or any of the other states if some
of -marduic is specified), but I couldn't figure out how to express that
clearly.
This seems a bit hacky, but works well. There should be no reason that
static-http repo had to load dirstate.
Initially I tried to proxy os.stat() call through vfs so that statichttpvfs
could hook it, but there wasn't a good error value which the statichttpvfs
could return to get around the util.filestat issue.
If we're going to use the user's installed and configured hg command
(which we do since a4a6cb293e63), we should prevent devel-warn messages
from interfering with locating it.
The short options "-c" and "-C" may be confusing for a novice reading the
documentation. Let's try to be more explicit, also mentioning the equivalent
long options ("--check" and "--clean") in the comments.
If the legacy pager extension is enabled, a pager is started through repo.ui
at dispatch._runcommand(). After that, mqcommand() creates a qrepo with a
fresh repo.baseui, at which point pager information was lost and another pager
would be spawned by the modern pager interface.
This is a minimal workaround for the problem.
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
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
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
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
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
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
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.
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
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.
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.
4d7cfa1867b5), 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.
ajaxScrollInit is a function that loads more elements (e.g. changelog entries)
when browser window is scrolled down to the bottom of the page. It basically
fetches the next page from the server as HTML, finds container element in that
document and "adopts" (essentially, moves) all its child nodes to the container
in the current document.
Currently, hgweb doesn't render any changesets on /graph page (everything is
done in JavaScript), so there are no children to adopt. But there will be soon,
so let's create a reusable function that does it.
Hardcoding #graphnodes selector is suboptimal, but graph code already does this
in two other places.
We do the same thing on clone for the largefiles extension, as a convenience.
Similar to largefiles, it's probably safer to only enable this extension on a
per repo basis because it is trivial to add an lfs file. And that gives the
repository some centralized VCS characteristics.
This makes sure that all columns are aligned. getlogcolumns() is hosted by
templatekw so the namespaces module can see it.
i18n/de.po is updated so test-log.t passes with no error. "obsolete:" and
"instability:" are kept untranslated.
We add a new 'ui.timeout.warn' config to set a grace period before we display
lock related warning:
waiting for lock on PATH held by PROCESS
The config is based on 'ui.timeout' and expresses a number of seconds before
the warning is displayed. Negative values disable the warning altogether.
The messages go to the debug output to help people trouble-shooting deadlocks.
We are about to make the messages around lock more flexible. We move all the
currently logic into a function in the lock module. We'll update the message
scheme in the next changeset.
