- Sep 17, 2015
- Sep 14, 2015
-
-
Yuya Nishihara authored
If commit is aborted by pretxncommit hook, in-memory changelog and manifest have entries that would be added. So they must be discarded on invalidate(). But the mechanism introduced by a710936c3037 doesn't handle this case well. It tries to mitigate the penalty of invalidate() by marking in-memory cache as "clean" on unlock assuming that they are identical to the stored data. But this assumption is wrong if stored data are rolled back by tr.abort(). This patch moves the hook to post-close action so that it will never be triggered on abort. This bug was originally reported to thg, which is only reproducible in command-server process on unix, evolve disabled. https://bitbucket.org/tortoisehg/thg/issues/4285/
-
- Sep 15, 2015
-
-
Yuya Nishihara authored
It only captures "self", so it isn't necessary to be created dynamically.
-
- Sep 16, 2015
-
-
Anton Shestakov authored
Highlight extension lacked a way to limit files by size, by extension, and/or by any other part of file path. A good solution would be to use a fileset, since it can check file path, extension and size (and more) in one expression. So this change introduces such an option, highlighfiles, which takes a fileset and on each request decides if the requested file should be highlighted. The default "size('<5M')" is, in a way, suggested in issue3005. checkfctx() limits the amount of work to just one file (subset kwarg in fileset.matchctx()). Monkey-patching works around issue4568, otherwise using filesets here while running hgweb in directory mode would say, for example, "Abort: **.py not under root", but this fix is very local and probably far from ideal. I suspect there to be a way to fix this for the whole hgweb and resolve the issue, but I don't know how to do it.
-
- Sep 04, 2015
-
-
timeless authored
-
- Sep 12, 2015
-
-
Gregory Szorc authored
If code inside a context manager returns a generator, the context manager exits before the generator is iterated. hgweb was using a context manager to control thread safe access to a localrepository instance. But it was returning a generator, so there was a race condition between a previous request streaming a response to the client and a new request obtaining the released but in use repository. By iterating the generator inside the context manager, we ensure we don't release the repo instance until after the response has finished. With this change, hgweb finally appears to have full localrepository isolation between threads. I can no longer reproduce the 2 exceptions reported in issue4756. test-hgweb-non-interactive.t has been modified to consume the output of calling into a WSGI application. Without this, execution of the WSGI application stalls because of the added yield statement.
-
- Aug 27, 2015
-
-
Augie Fackler authored
This was the first ever feature request for histedit, originally filed back on April 4, 2009. Finally fixed. In the future we'll probably want to make it possible for other preprocessing steps to be added to the list, but for now we're skipping that because it's unclear what the API should look like without a proposed consumer.
-
- Sep 14, 2015
-
-
Anton Shestakov authored
In paper and Coal, basically, div.sourcelast was only used to make a 1px border on the bottom of file source view (and only there). It's better to use bottomline class, that also exists for the same purpose (visually), but is used more widely and works without needing an empty <div>.
-
- Sep 13, 2015
-
-
Anton Shestakov authored
Basically, coal style in hgweb is intended to be functionally equivalent (just different in style) to paper, and does this by reusing almost all templates from paper (except header.tmpl, where it specifies a different css file). Looks like everybody forgot this and so many improvements to paper templates, that should've also made it into coal, were often only half-done there (usually thanks to template reuse). Let's fix this by bulk-copying missing things from paper/map and style-paper.css to coal/map and style-coal.css. There were many improvements to paper that didn't touch coal, and that makes it hard to untangle the code and split this patch into many, but here are some of the changes (paper-only), that now get into coal: 41c4bdd1d585 - hgweb: color line which is linked to in file source view f3393d458bf5 - hgweb: highlight line which is linked to at annotate view f2e4fdb3dd27 - hgweb: code selection without line numbers in file source view 5ec5097b4c0f - hgweb: add line wrapping switch to file source view bf661a03fddc - hgweb: use css margin instead of empty <p> before diffstat table It also fixes line anchor in annotateline template (#42 vs #l42).
-
- Sep 12, 2015
-
-
Gregory Szorc authored
revlog instances can cache the full text of a single revision. Typically the most recently read revision is cached. When adding a delta group via addgroup() and _addrevision(), the full text isn't always computed: sometimes only the passed in delta is sufficient for adding a new revision to the revlog. When writing the changelog from a delta group, the just-added full text revision is always read immediately after it is written because the changegroup code needs to extract the set of files from the entry. In other words, revision() is *always* being called and caching the full text of the just-added revision is guaranteed to result in a cache hit, making the cache worthwhile. This patch adds support to _addrevision() for always building and caching the full text. This option is currently only active when processing changelog entries from a changegroup. While the total number of revision() calls is the same, the location matters: buildtext() calls into revision() on the base revision when building the full text of the just-added revision. Since the previous revision's _addrevision() built the full text and the the previous revision is likely the base revision, this means that the base revision's full text is likely cached and can be used to compute the current full text from just a delta. No extra I/O required. The end result is the changelog isn't opened and read after adding every revision from a changegroup. On my 2013 MacBook Pro running OS X 10.10.5 from an SSD and Python 2.7, this patch impacted the time taken to apply ~262,000 changesets from a mozilla-central gzip bundle: before: ~43s after: ~32s ~25% reduction in changelog processing times. Not bad.
-
Gregory Szorc authored
The purpose of this code was to provide thread safety. With the conversion of hgweb to use separate localrepository instances per request/thread, we should no longer have any consumers that need to access revlog instances from multiple threads. Remove the code.
-
Gregory Szorc authored
Increase readability.
-
Gregory Szorc authored
cachedlocalrepo.copy() didn't actually create new localrepository instances. This meant that the new thread isolation code in hgweb wasn't actually using separate localrepository instances, even though it was properly using separate cachedlocalrepo instances. Because the behavior of the API changed, the single caller in hgweb had to be refactored to always call _webifyrepo() or it may not have used the proper filter. I confirmed via print() debugging that id(repo) is in fact different on each thread. This was not the case before. For reasons I can't yet explain, this does not fix issue4756. I suspect there is shared cache somewhere that isn't thread safe.
-
- Sep 10, 2015
-
-
timeless authored
test-bad-extension would jitter if the format of the first line of hg help changed, which isn't relevant to its goal.
-
- Sep 11, 2015
-
-
timeless authored
support combining -c and -e previously -k was misdocumented: * the first line didn't mention it * the help half implied you could do help -k keyword topic with these changes, -k just changes the search method support -c and -e for -k searches
-
- Sep 10, 2015
-
-
timeless authored
-
- Sep 13, 2015
-
-
Jordi Gutiérrez Hermoso authored
In e86d12404d69 I very embarrassingly wrote a patch with the completely wrong function name. This should fix it.
-
- Sep 10, 2015
-
-
Augie Fackler authored
This makes the documentation on ui.log line up with the use of that interface in blackbox.
-
- Sep 11, 2015
-
-
Yuya Nishihara authored
Because revset() function generates a list of revisions, it seems sensible to switch the ctx as well where a list expression will be evaluated. I think "{revset(...) % "..."}" expression wasn't considered well when it was introduced at cda9d2b6beab.
-
- Sep 10, 2015
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
-
Yuya Nishihara authored
revset and fileset have a similar problem, so let's make it a common helper function.
-
Pierre-Yves David authored
When general delta is enabled, the base is actually meaningful and should be used. With general delta is enabled, test-unionrepo.t crash without this fix.
-
Matt Harbison authored
Not sure how useful this really is, but it's trivial to add and ignoring the existing arguments supported seems like a bad UI.
-
Matt Harbison authored
One of the things I missed the most when transitioning from versioned MQ to evolve was the loss of being able to check that rebase conflicts were properly resolved by: $ hg ci --mq -m "before" $ hg rebase -s qbase -d tip $ hg bcompare --mq The old csets stay in the tree with evolve, but a straight diff includes all of the other changes that were pulled in, obscuring the code that was rebased. Diffing deltas can be confusing, but unless radical changes were made during the resolve, it is very clear when individual hunks are added, dropped or modified. Unlike the MQ technique, this can only compare a single pair of csets/patches at a time. Like the MQ method, this also highlights changes in the commit comment and other metadata. I originally tried monkey patching from the evolve extension, but that is too complicated given that it depends on the order the two different extensions are loaded. This functionality is also useful when comparing grafts however, so implementing it in the core is more than just convenience. The --change argument doesn't make much sense for this, but it isn't harmful so I didn't bother blocking it. The -I/-X options are ignored because of a limitation of cmdutil.export(). We'll fix that next.
-
Matt Harbison authored
This is purely indenting under an unconditional branch, so that the actual changes in the next patch are clear. Feel free to fold them if desired.
-
- Sep 11, 2015
-
-
Matt Mackall authored
-
- Sep 10, 2015
-
-
Augie Fackler authored
This breaks building manpages, and by association breaks building debs. timeless has a fix coming, but it turns out we'll need to back out 5f2a1ebd6e78 anyway, so just back it out now to fix building packages.
-
Jordi Gutiérrez Hermoso authored
There are two non-interactive internal merge tools, :other and :local, but they don't really merge, they just pick all changes from the local or other version of the file. In some situations, it is known that we want a merge and also know that all merge conflicts should be resolved in one direction. Although external merge tools can do this, sometimes it can be convenient to do so from within hg, without invoking a merge tool. These new :merge-local and :merge-other tools can do just that.
-
- Aug 12, 2015
-
-
Jordi Gutiérrez Hermoso authored
With this change, the simplemerge algorithm grows an option to only return the local or the other hunk in a conflicting region.
-
- Aug 26, 2015
-
-
Matt Mackall authored
The existing header/footer components were templated per-changeset, and thus couldn't be correctly printed for an empty log
-
- Sep 10, 2015
-
-
Augie Fackler authored
Suggested by Anton Shestakov <engored@ya.ru> on the list. Thanks!
-
- Aug 23, 2015
-
-
Gregory Szorc authored
Before this change, multiple threads/requests could share a localrepository instance. This meant that all of localrepository needed to be thread safe. Many bugs have been reported telling us that localrepository isn't actually thread safe. While making localrepository thread safe is a noble cause, it is a lot of work. And there is little gain from doing so. Due to Python's GIL, only 1 thread may be processing Python code at a time. The benefits to multi-threaded servers are marginal. Thread safety would be a lot of work for little gain. So, we're not going to even attempt it. This patch establishes a pool of repos in hgweb. When a request arrives, we obtain the most recently used repository from the pool or create a new one if none is available. When the request has finished, we put that repo back in the pool. We start with a pool size of 1. For servers using a single thread, the pool will only ever be of size 1. For multi-threaded servers, the pool size will grow to the max number of simultaneous requests the server processes. No logic for pruning the pool has been implemented. We assume server operators either limit the number of threads to something they can handle or restart the Mercurial process after a certain amount of requests or time has passed.
-
Gregory Szorc authored
hgweb contained code for determining whether a cached localrepository instance was up to date. This code was way too low-level to be in hgweb. This functionality has been moved to a new "cachedlocalrepo" class in hg.py. The code has been changed slightly to facilitate use inside a class. hgweb has been refactored to use the new API. As part of this refactor, hgweb.repo no longer exists! We're very close to using a distinct repo instance per thread. The new cache records state when it is created. This intelligence prevents an extra localrepository from being created on the first hgweb request. This is why some redundant output from test-extension.t has gone away.
-
Gregory Szorc authored
We perform some common tasks when a new repo instance is obtained. In preparation for changing how we obtain repo instances, factor this functionality into a standalone function.
-