Always write the undo file. Otherwise, rollback will not work for
the initial bookmark as undo.bookmarks doesn't exists. In this case
undo.bookmarks needs already be empty.
If pywin32 is not installed, 'os.lstat(pathname).st_nlink' is used for
nlinks(), which is always zero for all files on Windows.
To make sure we break up hardlinks if pywin32 is missing, we force
nlink = 2 if nlinks() returns < 1.
(this completely fixes issue1922)
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.
This turns the prompt sequence from something like:
$ examine changes to foo?
$ record change 1/4 to foo?
$ record change 2/4 to foo?
$ examine changes to bar?
$ record change 4/4 to bar?
into:
$ examine changes to foo?
$ record change 1/3 to foo?
$ record change 2/3 to foo?
$ examine change to bar?
$ record change 3/3 to bar?
The previous loop was iterating over a mixed header/hunk stream. It may have
been more generic in the sense every item in the stream could trigger a prompt
but it required more work to skip items properly. It can be rewritten in a more
intuitive way by looping on files then looping on hunks.
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.
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.
* remove obsolete reference to potential problems with merge and import
* emphasize that running kwshrink before configuration changes which
affect active/expanded keywords is mandatory
