On Windows, os.rename reliably raises OSError with errno.EEXIST if the
destination already exists (even on shares served by Samba).
Windows does *not* silently overwrite the destination of a rename.
So there is no need to first call os.path.exists on the chosen temp path.
Trusting os.path.exists is actually harmful, since using it enables the
following racy sequence of actions:
1) os.path.exists(temp) returns False
2) some evil other process creates a file with name temp
3) os.rename(dst, temp) now fails because temp has been taken
Not using os.path.exists and directly trying os.rename(dst, temp)
eliminates this race.
Preventing file loss repository corruption (e.g. vanished changelog.i) when
Mercurial pushes to repositories on Windows shares served by Samba.
This is a workaround for Samba bug 7863, which is present in current latest
stable Samba 3.5.6 and various prior versions down to 3.0.26a (the oldest one
I tested).
Of course this should be fixed in Samba, but there probably aren't that many
other applications who use hardlinks that extensively and keep files open like
Mercurial, so the pressure to fix this on Samba is probably not that high. And
even if the Samba project should be able to fix their bug within a month or
two, it will take quite some time until users upgrade their Samba installs.
Before this patch, the copy order on clone was:
requires
00changelog.i
store\data
store\00manifest.d
store\00manifest.i
store\00changelog.d
store\00changelog.i
store\dh
store\fncache
Which provides a theoretical non-zero probability of a race during clone where
a very early reader might see a repository with missing revlog files if it sees
00changelog.i before all files inside dh have been copied.
The dh directory is similar to the data directory -- just for files with long
names (which are hashed). The manifest refers to files in data *and* dh, so dh
should be copied before the manifest.
This patch improves the copy order to:
requires
00changelog.i
store\data
store\dh
store\fncache
store\00manifest.d
store\00manifest.i
store\00changelog.d
store\00changelog.i
I'm putting fncache to before the manifest while I'm at it, since fncache
provides a mechanism to enumerate all repository files without visiting the
manifest revisions. fncache depends only on data and dh.
Note that data must be copied first, since copying data triggers the creation
of the repository write lock in the destination repo (see hg.clone).
Mercurial will verify HTTPS server certificates if web.cacerts is configured,
but it will by default silently not verify any certificates.
We now warn the user that when the certificate isn't verified she won't get the
security she might expect from https:
warning: localhost certificate not verified (check web.cacerts config setting)
Self-signed certificates can be accepted silently by configuring web.cacerts to
point to a suitable certificate file.
Since it's usually only desirable to make tag commits on top of branch
heads, abort if the working dir parent is not a branch head. -f/--force
may be passed to commit at a non-head anyway.
Does not abort if working dir parent is a named branch head but not a
topological head.
This patch corrects the check for tagging on an uncommitted merge. We
should never commit a new tag changeset on an uncommitted merge, whether
or not --rev is specified. It also changes the error message from:
abort: cannot partially commit a merge (do not specify files or patterns)
to the much more accurate (and terse):
abort: uncommitted merge
Local tags are ok.
This more closely matches how the other undo files are created, and we
don't care about settings permissions or times on the file, which can
fail if the user running hg doesn't own the file.
This mainly affects hgweb, which can generate tar.gz archives without
filenames. Without this change, the header would be set to ".gz",
which can confuse Safari into extracting the file and renaming it to
"gz" when "Open 'safe' files after downloading" is enabled.
file(1) before:
hg-crew-439421eab08d.tar.gz: gzip compressed data, was ".gz", last modified: Thu Dec 2 11:46:20 2010, max compression
after:
hg-crew-439421eab08d.tar.gz: gzip compressed data, last modified: Thu Dec 2 11:46:20 2010, max compression
Do not pass reject file content to patchfile.writelines() to:
- Avoid line endings transformations
- Avoid polluting overriding implementations with unrelated data. They should
override write_rej() to deal or ignore reject files properly.
Bug report, analysis and original patch and test by
Shun-ichi GOTO <shunichi.goto@gmail.com>
1) hg cp symlink copy -> copy is a symlink.
2) cp symlink copy; hg cp -A symlink copy -> copy is a regular file.
In the second case we have to follow the symlink to its target
to find out whether we have to unexpand keywords in the copy.
Add test covering the case where the copied link's target is ignored
by keyword but has content which would match the regex for expanded
keywords to check whether we indeed leave the destination alone.
Improved help to make it more clear for users which changes are only
changes in the working copy and which changes that will go into the
repository (on the following commit). Futhermore a note on when the
rules will be applied to the working directory.
8aa8db6deb47 moved the subdirectory match inside the repository match
loop. A virtual path existing/path/invalid/path would then match
existing/path, and generate a wrong index page.
Additions to test-mq-qrefresh.t in 0880564992de (mq: ignore subrepos
(issue2499)) were originally based on a version prior to 42fb7ef18fb4
(subrepo: handle missing subrepo spec file as removed). This fixes a
test failure that resulted from the former being applied after the
latter, noticed by abuehl.
The case
$ hg clone a ''
already aborted before c1e68cd8cfa8, whereas
$ hg clone --pull a ''
tripped the fixed issue2528.
Both basic cases are expected to fail with an abort.
--bundle 3 leaves all of the compiled C extensions and other DLLs outside of
the library.zip, so we no longer add the installer folder to the system PATH.
Instead, we now ship a small bin/hg.cmd and it is placed in the PATH.
Switching to py2exe --bundle 3 is necessary because the higher bundle options
are not supported on x64.
Python's time.gmtime(lt) fails on Windows, producing a traceback with
ValueError: (22, 'Invalid argument')
if lt < -43200.
We get a local time boundary value of -43200 if we take "the epoch"
Thu Jan 01 00:00:00 1970 = time.gmtime(0)
from timezone 'UTC+0' into timezone 'UTC-12'. All other timezones will have
larger local time values for that point in time.
Aborting with a traceback on 'hg log' for revisions with a timestamp value
< -43200 is clearly not acceptable.
Returning "invalid timestamp" or similar as string representation is not an
option either, since that may crash other tools which parse the output of
'hg log'.
Instead, we teach util.datestr() to return the epoch in timezone UTC+0 on
*all platforms*, represented by the string
Thu Jan 01 00:00:00 1970 +0000
if the timestamp's unix time value is negative.
(based on a patch originally proposed by Benjamin Pollack)
If os_link fails on Windows, errno is always errno.EINVAL,
so we can't really say if the testlink could not be created
because (a) the FS doesn't support hardlinks or (b) there
is a leaked .hgtmp file lying around from a previous crashed
run.
So let's err on the safe side, keep the code simple and assume
we can't detect hardlinks in both cases.
If MQ allows modifying .hgsub or .hgsubstate in a patch, it can easily
lead to an inconsistent subrepo state. This patch prevents qrefresh from
adding any modifications to .hgsub or .hgsubstate to a patch. The user
is warned that these files are not included in the patch.
The tests test both the slightly irrational and the pathological cases.
