Concurrency in a GIT repo on a network shared folder

Question

I want to have a bare git repository stored on a (windows) network share. I use linux, and have the said network share mounted with CIFS. My coleague uses windows xp, and has the network share automounted (from ActiveDirectory, somehow) as a network drive.

I wonder if I can use the repo from both computers, without concurrency problems.

I've already tested, and on my end I can clone ok, but I'm afraid of what might happen if we both access the same repo (push/pull), at the same time.

In the git FAQ there is a reference about using network file systems (and some problems with SMBFS), but I am not sure if there is any file locking done by the network/server/windows/linux - i'm quite sure there isn't.

So, has anyone used a git repo on a network share, without a server, and without problems?

Thank you,
Alex

PS: I want to avoid using an http server (or the git-daemon), because I do not have access to the server with the shares. Also, I know we can just push/pull from one to another, but we are required to have the code/repo on the share for back-up reasons.

Update:

My worries are not about the possibility of a network failure. Even so, we would have the required branches locally, and we'll be able to compile our sources.

But, we usually commit quite often, and need to rebase/merge often. From my point of view, the best option would be to have a central repo on the share (so the backups are assured), and we would both clone from that one, and use it to rebase.

But, due to the fact we are doing this often, I am afraid about file/repo corruption, if it happens that we both push/pull at the same time. Normally, we could yell at each other each time we access the remote repo :), but it would be better to have it secured by the computers/network.

And, it is possible that GIT has an internal mechanism to do this (since someone can push to one of your repos, while you work on it), but I haven't found anything conclusive yet.

Update 2:

The repo on the share drive would be a bare repo, not containing a working copy.

Trumpetweed

Thanks for the question Alex, I'm facing similar situation and this was very helpful. Some points to add: you need to be shure that you both are using same versions of git, because the windows and the linux exe's will work on the same bare repo over the network share and in theory it is possibe to have some difference between versions. Probably not but just a flag that you need to have in mind. – Restful

See also: #1490042 – Metonym

It might be useful to limit the number of simultaneous users to 1 by going to the Advanced Sharing option for the folder – Balcke

Answer 1

Git requires minimal file locking, which I believe is the main cause of problems when using this kind of shared resource over a network file system. The reason it can get away with this is that most of the files in a Git repo--- all the ones that form the object database--- are named as a digest of their content, and immutable once created. So there the problem of two clients trying to use the same file for different content doesn't come up.

The other part of the object database is trickier-- the refs are stored in files under the "refs" directory (or in "packed-refs") and these do change: although the refs/* files are small and always rewritten rather than being edited. In this case, Git writes the new ref to a temporary ".lock" file and then renames it over the target file. If the filesystem respects O_EXCL semantics, that's safe. Even if not, the worst that could happen would be a race overwriting a ref file. Although this would be annoying to encounter, it should not cause corruption as such: it just might be the case that you push to the shared repo, and that push looks like it succeeded whereas in fact someone else's did. But this could be sorted out simply by pulling (merging in the other guy's commits) and pushing again.

In summary, I don't think that repo corruption is too much of a problem here--- it's true that things can go a bit wrong due to locking problems, but the design of the Git repo will minimise the damage.

(Disclaimer: this all sounds good in theory, but I've not done any concurrent hammering of a repo to test it out, and only share them over NFS not CIFS)

Darden

Thank you! For some explanation like this I was looking for. I will give it a try, and see if anything bad happens, and I'll update this question. Have a nice day! – Trumpetweed

can you provide a URL or something where this is covered in more depth? it's really interesting – Killifish

Answer 2

Why bother? Git is designed to be distributed. Just have a repository on each machine and use the publish and pull mechanism to propagate your changes between them.

For backup purposes, run a nightly task to copy your repository to the share.

Or, create one repository each on the share and do your work from them but use them as distributed repositories from which you can pull changesets from each other. If you use this method, then performance of doing builds and so on will be decreased since you will be constantly accessing over the network.

Or, have distributed repositories on your own computers, and run a periodic task to push your commits to the repositories on the share.

Isar

I think that real question from alexandrei is not about distributed nature but what will happen if push will fail due to CIFS/windows share failure (mounting problems, disconnect, etc.) – Involucre

I get that, my point is, why bother with the worry? You don't have to if you simply use git the way it is designed – Isar

I think that the last -or- point here answers the question quite elegantly. Just have each computer's repo be automatically pushed onto the share at different times. – Casuistry

Thank you all for these comments - it helps me to see how others think for a solutionto this. The worry is not about a network failure (it's distributed), but about the fact that witout a server, there is no access queue to the repo's internal files, which may result in currupted information. – Trumpetweed

The main point to keep in mind here is that you simply should not share a working copy. This introduces the probability that someone's changes in the working copy will be overwritten by someone elses. – Isar

"This introduces the probability that someone's changes in the working copy will be overwritten by someone elses." Ah, this is exactly my worry here, but thinking not about a working copy, but about a "bare" repository. – Trumpetweed

Answer 3

Sounds just as if you'd rather like to use a centralized versioning system, so the query for backup is satisifed. Perhaps with xxx2git in between for you to work locally.

Immunology

That is what we're currently doing, with SVN in between - but it's the same issue, no server, we're using it file based. This was one of the reasons to switch to GIT (and the fact that it better matches our work, to switch between different branches in the same workcopy) – Trumpetweed