A subversion project revisions are a subset of the repository revisions, you
can ask subversion to update a working directory from one revision to another
without changing anything. Unfortunately, Mercurial will think the
subrepository has changed and will commit it again. To avoid useless commits,
we compare the subrepository state to its actual "parent" revision. To ensure
ascending compatibility with existing subrepositories which might reference
fake revisions, we also keep comparing with the subrepo working directory
revision.
NOTE: not sure if this should go in stable or not.
Some extensions (e.g. hgsubversion) completely override push command. Because
extensions load order is unspecified, if hgsubversion loads before mq, mq
checks about not pushing applied patches will be bypassed. Short of finding a
way to fix load order, extracting the checking logic will allow
hgsubversion-like extensions to run the check themselves.
windows: factor it out of rename
posix: add alias 'unlink' for os.unlink
Note that this new unlink function now has different semantics than the
unlink() we had before changeset 5c424b3de62c ("rename util.unlink to
unlinkpath").
SSLSocket.getpeercert() returns tuple containing unicode for 'subject'.
Since Mercurial does't support IDN at all, it just returns error for non-ascii
certname.
to work around http://support.microsoft.com/kb/899149.
Also, Microsoft's documentation of the CreateFile Windows API says (quote):
When an application creates a file across a network, it is better to use
GENERIC_READ | GENERIC_WRITE for dwDesiredAccess than to use
GENERIC_WRITE alone. The resulting code is faster, because the
redirector can use the cache manager and send fewer SMBs with more data.
This combination also avoids an issue where writing to a file across a
network can occasionally return ERROR_ACCESS_DENIED.
Just a little change to bring the comments in the dirty() methods of the
various subrepo classes into a uniform structure. This clarifies the
meaning of the states checked.
This makes 'hg update --clean' behave the same way for all three kinds
of subrepositories [hg, svn, git]. Before git subrepos did not take
the clean parameter into account, but just updated to the given
revision and merged uncommitted changes into that.
The generation of cache files like tags.cache and branchheads.cache is not an
actual reflection of things changing in the whole of the .hg directory (like eg
a commit or a rebase or something) but instead these cache files are just part
of bookkeeping. As such its convienant to allow various clients to ignore file
events to do with these cache files which would otherwise cause a double
refresh. Eg one refresh might occur after a commit, but the act of refreshing
after the commit would cause Mercurial to generate a new branchheads.cache which
would then cause a second refresh, for clients.
However if these cache files are moved into a directory like eg .hg/cache/ then
GUI clients on OSX (and possibly other platforms) can happily ignore file events
in this cache directory.
Now that the nodemap is lazily created, we use linear scanning back
from tip for typical node to rev mapping. Given that nodemap creation
is O(n log n) and revisions searched for are usually very close to
tip, this is often a significant performance win for a small number of
searches.
When we do end up building a nodemap for bulk lookups, the scanning
function is replaced with a hash lookup.
It tries to convert localstr to unicode before truncating.
Because we cannot assume that the given text is encoded in local encoding,
it falls back to raw string in case of unicode error.
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.
In a date like 10:30, there are two underspecified ends: the specific
end (seconds) and the broad end (day, month, year). When matching
"10:30", we need to allow the specific end to go from 0 to 59 seconds,
while the broad end is assumed to be today's date.
Similar handling applies for a date range like "Mar 1": year is fixed
to today, any time matches.
The actual order of dictionary items is implementation-defined in
Python, and differs between CPython and PyPy. With this change,
test-hooks.t passes with PyPy.
Currently we only support enabling TLS by using SMTP STARTTLS extension. But
not all the servers support it.
With this patch, user can choose which way to enable TLS:
* Default:
tls = none
port = 25
* To use STARTTLS:
tls = starttls
port = 465
* To use SMTP over SSL:
tls = smtps
port = 465
To keep backward compatibility, when tls = true, we use STARTTLS to enable TLS.
Signed-off-by: Zhigang Wang <w1z2g3@gmail.com>
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 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>
split can be more readable for longer lists like the list in
dirstate.invalidate. As dirstate.invalidate is used in wlock() and therefoe
used heavily, I think it's worth avoiding a split there too.
The only revision information yielded by the annotate view was the revision
number itself. The patch allows the use of per-line revision dates in the
corresponding templates.
If Linux is asked to open a filename with a trailing directory separator,
e.g. "foo/", the open fails with EISDIR. On AIX, the open succeeds, opening
file "foo". This causes test-mq-qnew to fail on AIX.
Fix by adding 'ends with directory separator' to the conditions checked
by the path auditor. Change test to expect auditor fail message.
Invalid extensions in hgext/ could in some cases cause a crash when searching
for unknown commands in disabled extensions.
With this change we issue a warning if extracting commands from the extensions
fails. Traceback is available on request.
Reported on https://bugzilla.redhat.com/show_bug.cgi?id=663183 with forest.py.
This patch conforms gitsubrepo code to the variable naming scheme of the other
subrepo implementations. All user-facing path references should be relative
to the root repository.
This patch prevents MQ from creating an inconsistent subrepo state. If
the .hgsub file has been changed, and none of the subrepos have
uncommitted changes, creating or updating a patch (using qnew, qrefresh,
or qrecord) will update .hgsubstate accordingly.
If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord
will abort.
Thanks to pmezard for proposing this solution.
issue2538 gives a case where a changeset is merged with its child (which is on
another branch), and to my surprise the result is a real merge with two
parents, not just a "fast forward" "merge" with only the child as parent.
That is essentially the same as issue619.
Is the existing behaviour as intended and correct?
Or is the following fix correct?
Some extra "created new head" pops up with this fix, but it seems to me like
they could be considered correct. The old branch head has been superseeded by
changes on the other branch, and when the changes on the other branch is merged
back to the branch it will introduce a new head not directly related to the
previous branch head.
(I guess the intention with existing behaviour could be to ensure that the
changesets on the branch are directly connected and that no new heads pops up
on merges.)
This patch avoids empty commit when .hgsubstate is dirty. Empty commit
was caused by .hgsubstate being updated back to the state of the
working copy parent when committing, if a user had changed it manually
and not made any changes in subrepositories.
The subrepository state from the working copies parent is compared
with the state calculated as a result of trying to commit the
subrepositories. If the two states are the same, then return None
otherwise the commit is just done.
The line: "committing subrepository x" will be written if there is
nothing committed, but .hgsubstate is dirty for x subrepository.
Despite its name, git-diff-index compares a revision to the files in the
working directory. This seems way less sketchy and more future proof than
parsing human-readable git-status.
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.
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.
Using svn subrepos on MacOSX with native python 2.6.1 results in a lot of
unexpected output caused by:
http://bugs.python.org/issue5099
subprocess.Popen.__del__ causes AttributeError (os module == None)
Avoiding dangling Popen instance solves the issue.
An identity check between a variable and a string literal was added to
the pushkey implementation in c77f1a86a050. While CPython will
normally intern strings and thus make the test safe, value identity is
what should be used here.
Regression from 9f0026001bfd. That previous commit is not supposed
to affect log calls without --follow, so we step out of this
codepath if follow is not True, and it's enough to fix the
regression.
When --follow is given, we fix the issue by taking into account
changesets that have a rev > maxrev to build the filegraph: even if
those files are not included in the final result, it's still needed
to walk correctly the graph from the end of the filelog to minrev, to
track accurately renames.
According to the API document, GetModuleFileName is the preferred way to
retrieve the filename of the current process. So we shouldn't try
GetModuleFileName'Ex' first.
Previously system_rcpath_win32() happened to return unicode paths due to
GetModuleFileNameEx (issue2480). This problem is fixed as GetModuleFileName
never return unicode.
While this situation should never under normal use, some real
life repos sometimes contain such changesets (older hg versions,
broken rebases, etc...)
hgweb was displaying an "Internal error" in this case, and graphlog
displayed a redundant branch all the way to null: it does not cost us
much to just ignore this extra parent when constructing the DAG.
The Linux CIFS kernel driver (even in 2.6.36) suffers from a hardlink
count blindness bug (lstat() returning 1 in st_nlink when it is expected
to return >1), which causes repository corruption if Mercurial running
on Linux pushes or commits to a hardlinked repository stored on a Windows
share, if that share is mounted using the CIFS driver.
This patch works around issue1866 and improves the workaround done in
65e082ae3076 to fix issue761, by teaching the opener to lazily execute a
runtime check (new function checknlink) to see if the hardlink count
reported by nlinks() can be trusted.
Since nlinks() is also known to return varying count values (1 or >1)
depending on whether the file is open or not and depending on what client
and server software combination is being used for accessing and serving
the Windows share, we deliberately open the file before calling nlinks() in
order to have a stable precondition. Trying to depend on the precondition
"file closed" would be fragile, as the file could have been opened very
easily somewhere else in the program.
We were not returning the correct result if nullrev was in revs, as we
are checking parent(currentrev) != nullrev before yielding currentrev
test-convert-hg-startrev was wrong: if we start converting from rev -1 and
onwards, all the descendants of -1 (full repo) should be converted.
- Don't call atomictempfile or nlinks() if the path is malformed
(no basename). Let posixfile() raise IOError directly.
- atomictempfile already breaks up hardlinks, no need to poke
at the file with nlinks() if atomictemp.
- No need to copy the file contents to break hardlinks for 'w'rite
modes (w, wb, w+, w+b). Unlinking and recreating the file is faster.
When parentdelta is enabled, we choose the delta that has the minimum
distance to its base. Otherwise, base may be sufficiently far away to
require a full version, resulting in greatly reduced compression.
The current implementation of colwidth was treating 'A'mbiguous
characters as wide, which was incorrect in a non-East Asian context.
As per http://unicode.org/reports/tr11/#Recommendations, we should
instead default to 'narrow' if we don't know better. As character
width is dependent on the particular font used and we have no idea
what fonts are in use, this recommendation applies.
This introduces HGENCODINGAMBIGUOUS to get the old behavior back.
Currently, cmdutil.make_file() will return a freshly made file handle,
except when given a pattern of '-'. If callers would want to close the
handle, they would have to make sure that it's neither sys.stdin or
sys.stdout. Instead, returning a duplicate of either of the two
ensures that make_file() lives up to its name and creates a new
file handle regardless of the input.
This uses the same strategy as progress for pulls, estimating manifests
based on changeset count and estimating file count by files list in
each changeset.
This allows us to provide deterministic progress information during
transfer of bundle data over HTTP. This is required because we
currently buffer the bundle data to local disk prior to transfer since
wsgiref lacks chunked transfer-coding support.
The opener already unlinks the filename before 'w'riting, for both
the symlink and the normal file case. It also now resets the flags
for normal files on 'w'rite, which makes this os.unlink call completely
redundant.
For Windows, removing this extra unlink call helps to avoid tripping
issue2524 (os.unlink followed by a write).
In many common cases where the subrepo is up to date with the remote repo,
hg push will only need to run one git-branch command to see that nothing
needs to be pushed.
As well as simplifying the code, this makes subprocess calls about 25% faster.
Tested on a couple linux boxes.
python -mtimeit -s'import subprocess' 'subprocess.Popen(
"git version", shell=True, stdout=subprocess.PIPE).wait()'
python -mtimeit -s'import subprocess' 'subprocess.Popen(
["git","version"], stdout=subprocess.PIPE).wait()'
226847bf9cab updated copyfile to also copy over atimes and
mtimes. That behavior is specifically to trick editors into thinking
files that hg record has modified haven't changed. We don't really
care about preserving times in the general case.
This continues the strategy of separation between hg pull and hg update in
git subrepos by only dealing with git's branches on an update. This behavior
tries to cover the bare essentials of the semantics of git pull in the subrepo
when the parent repo does hg pull and hg update.
The Python default for this function is -1, indicating both relative
and absolute imports should be used.[1] Previously, we relied on the
Python VM not passing level when such semantics were
requisted. This is not the case for PyPy, however, where a level of -1
is always passed to __import__.
[1] <http://docs.python.org/library/functions.html#__import__>
Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
Avoids calls to git push when the revision is already known to be
in the remote repository. Now, when using a read-only git subrepo,
git will never need to talk to its upstream repository.
This enables minirst to parse and print option lists which have both
long and short options. Before, we could only parse option lists with
long options.
You can now split a list with a comment:
* foo
.. separator
* bar
and the two list items will no longer be run together, that is the
output is
* foo
* bar
instead of
* foo
* bar
With this patch applied, Mercurial will list the hashes of new remote heads
if push --debug aborts because of new remote heads (option -f/--force not set).
Example:
$ hg push --debug repo1
using http://example.org/repo1
http auth: user johndoe, password not set
sending between command
pushing to http://example.org/repo1
sending capabilities command
capabilities: changegroupsubset stream=1 lookup pushkey unbundle=HG10GZ,HG10BZ,HG10UN branchmap
sending heads command
searching for changes
common changesets up to 187dd3f0a37d
sending branchmap command
new remote heads on branch 'default' <- new output line
new remote head 5862c07f53a2 <- new output line
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Compare to without --debug (not changed by this patch, including it here
for reference purposes only):
$ hg push repo1
pushing to http://example.org/repo1
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Motivation for this change:
'hg outgoing' may list a whole lot of benign changesets plus an odd changeset
that will trigger the "new remote heads" abort. It can be hard to spot that
single unwanted changeset (it may be an old forgotten experiment, lingering
in the local repo).
"hg log -r 'heads(outgoing())'" might be useful, but that also lists a head
that may be benign on push.
Inside prepush(), we already know which heads are causing troubles on 'hg push'.
Why not make that info available (at least on --debug)?
This would also be helpful for doing remote support, as the supporter can ask
the user to paste the output of 'hg push --debug' on error and then ask further
questions about the heads listed.
- Handle 'subset' argument
- Stop returning the null rev from p1 and parents, as in the non-dirstate case
- Order parents as in the non-dirstate case (ascending revs)
This patch makes the 'set' argument to revset function parents() optional.
Like p1() and p2(), if no argument is given, returns the parent(s) of the
working directory.
Morally equivalent to 'p1()+p2()', as expected.
This patch makes the 'set' argument to revset functions p1() and p2()
optional. If no argument is given, p1() and p2() return the first or second
parent of the working directory.
If the working directory is not an in-progress merge (no 2nd parent), p2()
returns the empty set. For a checkout of the null changeset, both p1() and
p2() return the empty set.
- Don't call atomictempfile or nlinks() if the path is malformed
(no basename). Let posixfile() raise IOError directly.
- atomictempfile already breaks up hardlinks, no need to poke
at the file with nlinks() if atomictemp.
- No need to copy the file contents to break hardlinks for 'w'rite
modes (w, wb, w+, w+b). Unlinking and recreating the file is faster.
