This is perhaps related to an earlier question I asked here:
but we have now narrowed down this issue.
Here is the setup:
All of our development is performed on a NFS mounted folder. This is because we have very limited targets (embedded software group) and we must share limited HW in a common lab area. anyhow...
Our main SAN drive is setup to handle linux and windows. People tend to edit in Windows. All Builds are in linux. Each developer has their own drive that is mounted in their personal windows PC and linux build machines.
Another interesting datapoint, which we are trying to discuss with the SAN vendor:
/home/myNFS>touch newfile.txt /home/myNFS>ls -l newfile.txt -rwxr-xr-x 1 user group 0 Nov 16 17:00 newfile.txt
notice the executable bits are set.
from linux, on a local HDD:
/tmp>touch newfile.txt /tmp>ls -l newfile.txt -rw-rw-rw- 1 user group 0 Nov 16 17:01 newfile.txt
notice that the executable bits are NOT set.
In windows, all the files are shown with the correct status, as expected.
So, back to Mercurial.
When we clone a repository from Linux, all is well. However, when we later perform and update to a certain tag, SOMETIMES, RANDOM files have file mode status differences.
so, like this (all from linux):
hg clone hg st << all is ok hg update -C -r <<rev>> hg st << random files have mode problems. always with respect to the executable bit
anyhow, since the files are "random" this kinda smells like a race condition between Mercurial and the NFS filesystem... and clearly related to the odd default file creation behavior of our NFS drives to add exe bit status on file creation...
thoughts? We are researching with the SAN vendor, but maybe someone has an immediate better idea, or perhaps is aware of some issue here. It seems to me, that in some cases mercurial is failing to update the file mode status, especially with respect to the "update" command...?