I cringe when I see this for a number of reasons:
- It is not scale-able.
- It's not as fast as using a git server (bandwidth)
- If you access files on a Linux box the line endings are going to be different. In this case git can become confused and suggest that files have been changed when they have not been.
- Accessing this between work and home is slooow. You have to mount the drive and do the push pull to that drive.
- Accessing via a slow Atlantic VPN connection is very questionable in this case as you have now lost the distributed part of git.
- All your changes are on that share. If you loose a file or the file becomes corrupted you've got problems.
- Atomic File access and file-locking: It should work....
Atomic File Access and File-Locking:
This should work see Git Over NFS/CIFS
However I would not recommend this especially as you need up-to date Samba, NFS etc...
I have found that if you have a mixture of different Operating Systems for testing and supporting customers on specific Linux distributions (some quite old) ensuring that the network filesystems are all up-to date is very time consuming and sometimes not possible without modifying the source code.
Sometimes NFS file-locking is turned off due to compatabilities between versions or suppliers.
Recommendation:
Given that it does not take that long to setup a proper git-server I would not recommend a local git repository shared with other developers unless your environment is hetrogenous and all your developers are local on a fast network.
In other words: "Setup a Git-Server".
Comments
Post a Comment