Question

This is perhaps related to an earlier question I asked here:

http://kiln.stackexchange.com/questions/1854/hg-status-shows-all-files-modified-in-linux-but-not-windows

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:

from linux:

/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...?

Answer 1

If you cannot fix the issue, you can work around it quite easily by using local disks on all machines (assuming this is possible for you). If each developer has an appropriate repository (s)he can push to such as their own branch or a dev branch, DVCS works great with separate clones on each machine. I use it this way on my work machine, work VM, home Mac and home Windows VM.

Answer 2

we created a test drive on the SAN that was setup on the SAN for "unix/linux" only and repeated our experiments.

This fixes all the issues.

The SAN vendor said that our configuration of Windows/Linux on the same drive was generally not recommended. Yep.

Now... how to transition our existing network drives... fun!