Thu, 09 May 2013 11:37:20 +0900 blackbox: fix literal block syntax stable
Takumi IINO <trot.thunder@gmail.com> [Thu, 09 May 2013 11:37:20 +0900] rev 19162
blackbox: fix literal block syntax
Tue, 07 May 2013 05:04:11 +0900 largefiles: check unknown files with case awareness of the filesystem stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 07 May 2013 05:04:11 +0900] rev 19161
largefiles: check unknown files with case awareness of the filesystem Before this patch, largefiles extension checks unknown files in the working directory always case sensitively. This causes failure in updating from the revision X consisting of '.hglf/A' (and "A" implicitly) to the revision Y consisting of 'a' (not ".hglf/A") on case insensitive filesystem, because "A" in the working directory is treated as colliding against and different from 'a' on the revision Y. This patch uses "repo.dirstate.normalize()" to check unknown files with case awareness of the filesystem.
Tue, 07 May 2013 05:04:11 +0900 largefiles: check existence of the file with case awareness of the filesystem stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 07 May 2013 05:04:11 +0900] rev 19160
largefiles: check existence of the file with case awareness of the filesystem Before this patch, largefiles extension always unlinks largefiles untracked on the target context in merging/updating after updating working directory. For example, it is assumed that the revision X consists of ".hglf/A" (and "A" implicitly) and revision Y consists of "a" (not ".hglf/A"). In the case of updating from X to Y, largefiles extension tries to unlink "A" after updating "a" in working directory. This causes unexpected unlinking "a" on the case insensitive filesystem. This patch checks existence of the file in the working context with case awareness of the filesystem to prevent from such unexpected unlinking. "lfcommands._updatelfile()" also unlinks target file in the case "largefile is tracked in the target context, but fails to be fetched". This patch doesn't apply "repo.dirstate.normalize()" in this case, because it should be already ensured in the manifest merging that there is no normal file colliding against any largefiles.
Tue, 07 May 2013 05:04:11 +0900 windows: check target type before actual unlinking to follow POSIX semantics stable
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.
Thu, 09 May 2013 09:51:42 -0400 Merge with stable.
Augie Fackler <raf@durin42.com> [Thu, 09 May 2013 09:51:42 -0400] rev 19158
Merge with stable.
Wed, 08 May 2013 14:11:01 -0700 manifestmerge: local unknown, remote created: don't traverse symlinks
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.
Thu, 09 May 2013 21:09:58 +0900 subrepo: open files in 'rb' mode to read exact data in (issue3926) stable
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.
Thu, 04 Apr 2013 13:45:21 -0700 patch: use scmutil.marktouched instead of scmutil.addremove
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.
Thu, 04 Apr 2013 13:38:28 -0700 scmutil: add a function to mark that files have been operated on
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.
Wed, 03 Apr 2013 15:53:59 -0700 scmutil.addremove: factor out code to mark added/removed/renames
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip