FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 07 May 2013 05:04:11 +0900] rev 19159
windows: check target type before actual unlinking to follow POSIX semantics
Creation and writing into target file via vfs (a.k.a opener) is done
after "unlink()" target file, if it exists.
For example, it is assumed that the revision X consists of file 'A',
and the revision Y consists of file 'A/B'. Merging revision X into Y
tries to "unlink()" on directory 'A' of 'A/B', before creation of file
'A'.
On POSIX environment, directories should be removed by "rmdir(2)", and
"unlink(2)" on directories fails. "unlink()" of Mercurial (and Python)
uses "unlink(2)" directly, so unlinking in the merge case above would
fail.
In the other hand, on Windows environment, "unlink()" of Mercurial
tries to rename before actual unlinking, to follow POSIX semantics:
already opened file can be unlinked safely.
This causes unexpected success in unlinking in the merge case above,
even though directory 'A' is renamed to another. This confuses users.
This patch checks whether target is directory or not before renaming,
and raises IOError(errno.EPERM) if so, to follow POSIX semantics.
Augie Fackler <raf@durin42.com> [Thu, 09 May 2013 09:51:42 -0400] rev 19158
Merge with stable.
Siddharth Agarwal <sid0@fb.com> [Wed, 08 May 2013 14:11:01 -0700] rev 19157
manifestmerge: local unknown, remote created: don't traverse symlinks
To figure out what to do with locally unknown files, Mercurial attempts to read
them if they exist. When an attempt is made to read a file that exists but
traverses a symlink, Mercurial aborts.
With this patch, we first ensure that the file doesn't traverse a symlink
before opening it. This is fine because a file being "remote created" means the
symlink doesn't exist remotely, which means it will be deleted in the apply
phase.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 09 May 2013 21:09:58 +0900] rev 19156
subrepo: open files in 'rb' mode to read exact data in (issue3926)
Before this patch, "subrepo._calcfilehash()" opens files by "open()"
without any mode specification. This implies "text mode" on Windows.
When target file contains '\x00' byte, "read()" in "text mode" reads
file contents in without data after '\x00'.
This causes invalid SHA1 hash calculation in "subrepo._calcfilehash()".
This patch opens files in 'rb' mode to read exact data in.
Siddharth Agarwal <sid0@fb.com> [Thu, 04 Apr 2013 13:45:21 -0700] rev 19155
patch: use scmutil.marktouched instead of scmutil.addremove
addremove required paths relative to the cwd, which meant a lot of extra code
that transformed paths into relative ones. That code is now gone as well.
Siddharth Agarwal <sid0@fb.com> [Thu, 04 Apr 2013 13:38:28 -0700] rev 19154
scmutil: add a function to mark that files have been operated on
Several places use scmutil.addremove as a means to declare that certain files
have been operated on. This is ugly because:
- addremove takes patterns relative to the cwd, not paths relative to the root,
which means extra contortions for callers.
- addremove doesn't make clear what happens to files whose status hasn't
changed.
This new method accepts filenames relative to the repo root, and has a much
clearer contract. It also allows future modifications that do more with files
whose status hasn't changed.
Siddharth Agarwal <sid0@fb.com> [Wed, 03 Apr 2013 15:53:59 -0700] rev 19153
scmutil.addremove: factor out code to mark added/removed/renames
An upcoming patch will reuse this code in another function.
Siddharth Agarwal <sid0@fb.com> [Wed, 03 Apr 2013 16:32:41 -0700] rev 19152
scmutil.addremove: factor out code to find renames
This code will be used in a different context in upcoming patches.
Siddharth Agarwal <sid0@fb.com> [Wed, 03 Apr 2013 15:32:15 -0700] rev 19151
scmutil.addremove: rename local 'copies' to 'renames'
An upcoming patch will refactor some code out into a method called
_findrenames. Having a line saying "copies = _findrenames..." is confusing.
Besides, 'renames' is a more precise name for this local anyway.
Siddharth Agarwal <sid0@fb.com> [Tue, 02 Apr 2013 17:19:36 -0700] rev 19150
scmutil.addremove: factor out dirstate walk into another function
Upcoming patches will reuse and expand on this function for other purposes.
Durham Goode <durham@fb.com> [Wed, 01 May 2013 10:42:03 -0700] rev 19149
filecontext: use 'is not None' to check for filelog existence
Previously we used 'if filelog:' to check if the filelog existed. If the
instance did exist, this pattern then calls len() on the filelog to see
if it is empty. I'm developing a filelog replacement that doesn't have
len() implemented, so it's better to do an explicit 'is not None' check
here instead.
Also change _changeid() to return the _changeid attribute if it has it.
Previously it would try to obtain it from the _changectx(), and if that
did not exist it would construct the _changectx() using the linkrev. In
the extension I'm working on, filectx's don't have easy access to linkrevs
so avoiding this when possible is better.
Durham Goode <durham@fb.com> [Wed, 01 May 2013 10:39:37 -0700] rev 19148
filelog: use super() for calling base functions
filelog had some hardcoded revlog.revlog.foo() calls. This changes it to
use super() instead so that extensions can replace the filelog base class.
Kevin Bullock <kbullock@ringworld.org> [Thu, 02 May 2013 21:28:18 -0500] rev 19147
bookmarks: allow bookmark command to take multiple arguments
This change allows setting or deleting multiple bookmarks at once. If more than
one is being set and --inactive is not given, the first one is made active.
Matt Mackall <mpm@selenic.com> [Sun, 05 May 2013 18:51:34 -0500] rev 19146
merge with stable
Blesso hrvoje1212@gmail.com [Fri, 03 May 2013 19:34:59 +0200] rev 19145
convert: fix bug of wrong CVS path parsing without port number (issue3678)
The cvsps.py:getrepopath suffers from a string parsing bug (it returns
"user@server/path/to/repository" if the CVSROOT is given like this:
":pserver:user@server/path/to/repository" ), which gives returnes the wrong
value becouse cvsps.py fails to strip the prefix from filenames.
With this patch for the same input we get the correct repo path that is:
"/path/to/repository"
Siddharth Agarwal <sid0@fb.com> [Fri, 03 May 2013 15:36:18 -0700] rev 19144
match: add comments to explain explicitdir and traversedir
Siddharth Agarwal <sid0@fb.com> [Fri, 03 May 2013 14:41:58 -0700] rev 19143
match: make explicitdir and traversedir None by default
With this, extensions can easily tell when traversedir and/or explicitdir don't
need to be called.
Siddharth Agarwal <sid0@fb.com> [Fri, 03 May 2013 14:39:28 -0700] rev 19142
dirstate.walk: cache match.explicitdir and traversedir locally
Siddharth Agarwal <sid0@fb.com> [Sun, 28 Apr 2013 21:29:32 -0700] rev 19141
match: drop dir callback
dir has been subsumed by explicitdir and traversedir.
Siddharth Agarwal <sid0@fb.com> [Sun, 28 Apr 2013 21:28:31 -0700] rev 19140
inotify: call match.explicitdir
inotify only returns explicit directories matched.
Siddharth Agarwal <sid0@fb.com> [Sun, 28 Apr 2013 21:27:57 -0700] rev 19139
purge: hook into match.explicitdir and traversedir
Siddharth Agarwal <sid0@fb.com> [Sun, 28 Apr 2013 21:27:21 -0700] rev 19138
localrepo.commit: hook into match.explicitdir
Siddharth Agarwal <sid0@fb.com> [Sun, 28 Apr 2013 21:25:41 -0700] rev 19137
dirstate.walk: call match.explicitdir or traversedir as appropriate
Siddharth Agarwal <sid0@fb.com> [Sun, 28 Apr 2013 21:24:09 -0700] rev 19136
match: introduce explicitdir and traversedir
match.dir is currently called in two different places:
(1) noting when a directory specified explicitly is visited.
(2) noting when a directory is visited during a recursive walk.
purge cares about both, but commit only cares about the first.
Upcoming patches will split the two cases into two different callbacks. Why
bother? Consider a hypothetical extension that can provide more efficient walk
results, via e.g. watching the filesystem. That extension will need to
fall back to a full recursive walk if a callback is set for (2), but not if a
callback is only set for (1).
Matt Mackall <mpm@selenic.com> [Sat, 04 May 2013 14:52:51 -0500] rev 19135
merge with stable
Siddharth Agarwal <sid0@fb.com> [Fri, 03 May 2013 15:18:21 -0700] rev 19134
run-tests: when running in parallel, delete tmpdirs immediately
This is especially important if extensions that use inotify are enabled,
because it's very easy to hit the inotify max_user_instances limit without
this.
Brendan Cully <brendan@kublai.com> [Fri, 03 May 2013 14:19:30 -0700] rev 19133
tests: check path separator in moves
Brendan Cully <brendan@kublai.com> [Fri, 03 May 2013 13:59:58 -0700] rev 19132
tests: fix test-commandserver phase . output for windows
Matt Mackall <mpm@selenic.com> [Sat, 04 May 2013 14:51:21 -0500] rev 19131
hfs+: rewrite percent-escaper (issue3918)
The original code was a bit too clever and got confused by some cp949
Korean text. This rewrite bytes the bullet and manually decodes UTF-8
sequences. Adds some doctests.
Matt Mackall <mpm@selenic.com> [Fri, 03 May 2013 15:34:18 -0500] rev 19130
merge with stable
Bryan O'Sullivan <bryano@fb.com> [Fri, 03 May 2013 12:40:17 -0700] rev 19129
revert: ensure that copies and renames are honored (issue3920)
Previously, we restored the states of files, but not the additional
information the dirstate uses to track copies and renames.
Durham Goode <durham@fb.com> [Fri, 03 May 2013 09:44:50 -0700] rev 19128
hgignore: fix regression with hgignore directory matches (issue3921)
If a directory matched a regex in hgignore but the files inside the directory
did not match the regex, they would appear as deleted in hg status. This
change fixes them to appear normally in hg status.
Removing the ignore(nf) conditional here is ok because it just means we might
stat more files than we had before. My testing on a large repo shows this
causes no performance regression since the only additional files being stat'd
are the ones that are missing (i.e. status=!), which are generally rare.