Thu, 05 Sep 2013 11:45:27 -0400 merge with mpm
Augie Fackler <raf@durin42.com> [Thu, 05 Sep 2013 11:45:27 -0400] rev 19654
merge with mpm
Tue, 03 Sep 2013 17:06:19 -0400 merge with mpm
Augie Fackler <raf@durin42.com> [Tue, 03 Sep 2013 17:06:19 -0400] rev 19653
merge with mpm
Sat, 17 Aug 2013 20:48:49 -0700 pack_dirstate: only invalidate mtime for files written in the last second
Siddharth Agarwal <sid0@fb.com> [Sat, 17 Aug 2013 20:48:49 -0700] rev 19652
pack_dirstate: only invalidate mtime for files written in the last second Previously we'd place files written in the last second in the lookup set. This can lead to pathological cases where a file always remains in the lookup set if it gets modified before the next time status is run. With this patch, only the mtime of those files is invalidated. This means that if a file's size or mode changes, we can immediately declare it as modified without needing to compare file contents.
Sat, 31 Aug 2013 10:20:15 -0700 dirstate.status: don't ignore symlink placeholders in the normal set
Siddharth Agarwal <sid0@fb.com> [Sat, 31 Aug 2013 10:20:15 -0700] rev 19651
dirstate.status: don't ignore symlink placeholders in the normal set On Windows, there are two ways symlinks can manifest themselves: 1. As placeholders: text files containing the symlink's target. This is what usually happens with fresh clones on Windows. 2. With their dereferenced contents. This happens with clones accessed over NFS or Samba. In order to handle case 2, ca6cebd8734e made dirstate.status ignore all symlink placeholders on Windows. It doesn't ignore symlinks in the lookup set, though, since those don't have the link bit set. This is problematic because it violates the invariant that `hg status` with every file in the normal set produces the same output as `hg status` with every file in the lookup set. With this change, symlink placeholders in the normal set are no longer ignored. We instead rely on code in localrepo.status that uses heuristics to look for suspect placeholders. An upcoming patch will test this out by no longer adding files written in the last second of an update to the lookup set.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip