Laurent Charignon <lcharignon@fb.com> [Sat, 01 Aug 2015 05:43:39 -0700] rev 26031
devel-warn: issue a warning when writing bookmarks without holding the wlock
I saw an issue in an extension that we develop where we were writing bookmarks
without holding the wlock. Another extension was taking a lock at the same time
and wiped out the bookmarks we were about to write. This patch adds a
devel-warning to urge people to fix their invalid code.
Matt Mackall <mpm@selenic.com> [Thu, 13 Aug 2015 19:37:47 -0500] rev 26030
merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 11 Aug 2015 16:45:11 -0700] rev 26029
rebase: lock the repo during the full rebase operation
Running `hg pull --rebase` would move bookmarks without any repository locking.
So we now lock the repository. For good measure and avoiding sneaky race
conditions, we lock the repository for the whole operation.
There is no code change besides the indentation.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 11 Aug 2015 16:26:12 -0700] rev 26028
update: wlock the repo for the whole 'hg update' command
The update command is touching the repository and should lock it for
the length of its operations. Equally importantly, it should lock the
repository when it is writing bookmarks. It wasn't doing so until now,
leaving doors open for all kinds of drunk beaver parties.
This results in some minor tests changes, and the fixing of a couple
of bugs from race conditions.
Code does not receive any changes beside extra indentation.
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 13 Aug 2015 11:09:36 -0300] rev 26027
help: fix typo in scripting documentation
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 13 Aug 2015 15:07:07 +0900] rev 26026
hg: avoid auto sharing when the clone destination is remote
Before this patch, when auto sharing is enabled, 'hg.clone()' tries to
create local clone regardless of locality of the clone destination on
the host, and causes failure.
To avoid auto sharing when the clone destination is remote, this patch
adds examination of 'islocal(dest)' before auto sharing in
'hg.clone()'.
'islocal(dest)' is examined after 'sharepool', because:
- the former is more expensive than the latter
- without enabling share extension, the later is always negative
Matt Harbison <matt_harbison@yahoo.com> [Wed, 12 Aug 2015 12:26:39 -0400] rev 26025
largefiles: ensure lfutil.getstandinmatcher() only matches standins
Previously, simply having the largefiles extension loaded without any largefiles
added would crash when amending with -I. The problem was with no files in the
matcher, the pattern list of files joined with 'standindir' was empty, and
scmutil.match() would match everything. In lfutil.composestandinmatcher(), the
match function is used to test if the file is a standin, and after getting a
false positive, proceeds to call lfutil.splitstandin(). This returns None
because it isn't a standin, which blows up when passed to rmatcher.matchfn().
Manually overriding _always in getstandinmatcher() probably isn't necessary
anymore, but we leave well enough alone on stable. This regressed in
ab618e52788a.
Durham Goode <durham@fb.com> [Wed, 12 Aug 2015 19:44:21 -0700] rev 26024
dirstate: add --minimal flag to debugrebuilddirstate
On repositories with hundreds of thousands of files, hg
debugrebuilddirstate causes every dirstate entry to be marked lookup,
and the next hg status can take many minutes.
This adds a --minimal flag that allows us to only rebuild the parts of the
dirstate that are inconsistent. This follows two rules:
1) If a file is in the dirstate but not in the parent manifest, and it is not
marked 'add', it is busted and we should drop it.
2) If a file is not in the dirstate at all, but it is in the parent
manifest, it should be added to the dirstate and we need to mark it as
lookup.
This allows us to fix repositories where the dirstate doesn't match
the manifest much more quickly.
Tested by artificially adding bad dirstate entries (via code) for both cases
above.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 13 Aug 2015 22:10:52 +0900] rev 26023
tests: make filterpyflakes.py read target files relatively to cwd
Before this patch, 'filterpyflakes.py' reads target files relatively
to own location.
But this prevents third party tools from using it in own source tree,
because their files are placed separately from 'filterpyflakes.py'.
In fact, 'test-check-pyflakes.t', which is the only user of
'filterpyflakes.py', changes current working directory (cwd) to the
root of "test target" source tree before using it. Therefore,
composing the root of source tree in 'filterpyflakes.py' is redundant.
This patch makes 'filterpyflakes.py' read target files relatively to
cwd by invoking 'open()' without any path composition. This also
removes importing 'os' module, because there is no user of it after
this patch.
This is a one of preparation of
issue4677.
Anton Shestakov <av6@dwimlabs.net> [Tue, 11 Aug 2015 13:48:57 +0800] rev 26022
monoblue: remove duplicate font-family property from td.source
Anton Shestakov <av6@dwimlabs.net> [Tue, 11 Aug 2015 13:45:54 +0800] rev 26021
monoblue: remove unused elements and related css
Since
91b0ada2d94b and
c9b88695d894, when monoblue was introduced, the code
this patch removes was untouched. Presumably, there supposed to be nice
graphics in the screen corners, but there never were due to:
- the css being commented out
- ids of the elements and of the css selectors being different
- and the png files absent
The "corner" elements were unstyled and didn't affect the rest of the page, so
I think it's safe to remove all this.
Yuya Nishihara <yuya@tcha.org> [Thu, 13 Aug 2015 16:15:43 +0900] rev 26020
revpair: restrict odd-range handling to top-level x:y expression (
issue4774)
The odd-range hack was introduced by
2a0efa1112ac for backward compatibility,
but it was too widely applied. I've checked cmdutil.revpair() at 1.6, and
found that ".:", ":0" and ":" are also handled as pairs. So let's enable the
hack only for "x:y", "x:", "y:" and ":".
test-revset.t is updated because "tip^::tip^ or tip^" shouldn't be taken as
an odd range. This patch adds "tip^:tip^" instead.
This patch is written for the default branch because parse() of the stable
branch lacks compatibility hack for "foo+bar" tag. If we want to mitigate the
issue in stable, we can add something like "and '::' in revs[0]".