windows 网络共享文件夹上的 GIT 存储库中的并发

Concurrency in a GIT repo on a network shared folder

提问by Alex

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.

我想在（windows）网络共享上存储一个裸git存储库。我使用 linux，并且使用 CIFS 安装了上述网络共享。我的同事使用 windows xp，并将网络共享自动挂载（从 ActiveDirectory，不知何故）作为网络驱动器。

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

我想知道我是否可以在两台计算机上使用 repo，而不会出现并发问题。

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.

我已经测试过了，最后我可以克隆，但是我担心如果我们同时访问同一个 repo（推/拉）会发生什么。

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.

在 git FAQ 中有一个关于使用网络文件系统的参考（以及 SMBFS 的一些问题），但我不确定网络/服务器/windows/linux 是否有任何文件锁定 - 我很确定没有'不。

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

那么，有没有人在网络共享上使用过 git repo，没有服务器，没有问题？

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.

PS：我想避免使用 http 服务器（或 git-daemon），因为我无权访问带有共享的服务器。此外，我知道我们可以从一个推/拉到另一个，但出于备份原因，我们需要在共享上拥有代码/回购。

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 yellat 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.

而且，GIT 可能有一个内部机制来做到这一点（因为有人可以在你处理它的时候推送到你的一个存储库），但我还没有找到任何结论性的东西。

Update 2:

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

更新 2：

共享驱动器上的存储库将是一个裸存储库，不包含工作副本。

采纳答案by araqnid

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.

Git 需要最少的文件锁定，我认为这是在网络文件系统上使用这种共享资源时出现问题的主要原因。它可以逃脱的原因是 Git 存储库中的大多数文件——所有构成对象数据库的文件——都被命名为其内容的摘要，并且一旦创建就无法改变。因此，不会出现两个客户端尝试将同一文件用于不同内容的问题。

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_EXCLsemantics, 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.

对象数据库的另一部分更棘手——refs 存储在“refs”目录（或“packed-refs”）下的refs/*文件中，并且这些文件确实会发生变化：尽管文件很小并且总是被重写而不是被编辑。在这种情况下，Git 将新的 ref 写入一个临时的“.lock”文件，然后在目标文件上重命名它。如果文件系统尊重O_EXCL语义，那是安全的。即使没有，可能发生的最坏情况也是覆盖 ref 文件的竞争。尽管遇到这种情况会很烦人，但它不应该导致损坏：可能是您推送到共享存储库的情况，并且该推送看起来成功了，而实际上其他人已成功。但这可以通过拉（合并另一个人）来解决

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.

总而言之，我不认为 repo 损坏在这里是一个太大的问题——确实，由于锁定问题，事情可能会出现一些错误，但 Git repo 的设计会将损害降至最低。

(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)

（免责声明：理论上这一切听起来都不错，但我没有对 repo 进行任何并发锤击来测试它，并且只通过 NFS 而不是 CIFS 共享它们）

回答by 1800 INFORMATION

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.

何苦？Git 被设计为分布式的。只需在每台机器上都有一个存储库，并使用发布和拉取机制在它们之间传播您的更改。

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.

或者，在您自己的计算机上拥有分布式存储库，并运行定期任务将您的提交推送到共享上的存储库。

回答by 1800 INFORMATION

Apparently using a central git repo is supported. Most prescribed uses indicate ssh or http access, neither of which avoid the simultaneous access to the repo. Even if you are doing completely distributed usage, this question arises if more than two collaborators push to the same repo anywhere. So far, no response has answered the question. Does the design of git allows it to handle N simultaneous pushes to a branch?

显然支持使用中央 git 存储库。大多数规定的用途表明 ssh 或 http 访问，这两种方法都避免同时访问 repo。即使您正在完全分布式使用，如果有两个以上的协作者在任何地方推送到同一个 repo，就会出现这个问题。到目前为止，没有任何回应回答了这个问题。git 的设计是否允许它处理 N 个同时推送到一个分支？

回答by Leonidas

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.

听起来好像您更喜欢使用集中式版本控制系统，因此可以满足备份查询。也许 xxx2git 介于两者之间，以便您在本地工作。