concurrency em um repository GIT em uma pasta compartilhada de rede

Eu quero ter um repository git nua armazenado em um compartilhamento de rede (windows). Eu uso o Linux e tenho o dito compartilhamento de rede montado com o CIFS. Meu colega usa o windows xp e tem o compartilhamento de rede montado automaticamente (a partir do ActiveDirectory, de alguma forma) como uma unidade de rede.

Gostaria de saber se posso usar o repository de ambos os computadores, sem problemas de simultaneidade.

Eu já testei, e do meu lado eu posso clonar ok, mas tenho medo do que poderia acontecer se nós dois acessássemos o mesmo repo (push / pull), ao mesmo tempo.

No git FAQ há uma referência sobre o uso de filesystems de rede (e alguns problemas com o SMBFS), mas não tenho certeza se existe algum bloqueio de arquivo feito pela rede / servidor / windows / linux – eu tenho certeza que não há t.

Então, alguém usou um repository do git em um compartilhamento de rede, sem um servidor e sem problemas?

Obrigado,
Alex

PS: Eu quero evitar usar um servidor http (ou o git-daemon), porque eu não tenho access ao servidor com os compartilhamentos. Além disso, sei que podemos apenas empurrar / puxar de um para outro, mas precisamos ter o código / repo no compartilhamento por motivos de backup.

Atualizar:

Minhas preocupações não são sobre a possibilidade de uma falha de rede. Mesmo assim, teríamos as ramificações necessárias localmente e poderíamos compilar nossas fonts.

Mas, geralmente, cometemos com bastante frequência e precisamos rebase / mesclar com frequência. Do meu ponto de vista, a melhor opção seria ter um repo central no compartilhamento (para que os backups sejam garantidos), e nós dois clonaríamos esse, e usá-lo para rebase.

Mas, devido ao fato de estarmos fazendo isso com frequência, eu tenho medo da corrupção de arquivos / repo , se acontecer de nós dois empurrarmos / puxarmos ao mesmo tempo. Normalmente, poderíamos gritar um com o outro cada vez que acessamos o repository remoto :), mas seria melhor tê-lo protegido pelos computadores / rede.

E é possível que o GIT tenha um mecanismo interno para fazer isso (já que alguém pode enviar um dos seus repos, enquanto você trabalha nele), mas ainda não encontrei nada conclusivo.

Atualização 2:

O repo na unidade de compartilhamento seria um repository vazio, não contendo uma cópia de trabalho.

O Git requer o mínimo de bloqueio de arquivos, o que acredito ser a principal causa de problemas ao usar esse tipo de recurso compartilhado em um sistema de arquivos de rede. A razão disso é que a maioria dos arquivos em um repository do Git – todos os que formam o database de objects – são nomeados como um resumo de seu conteúdo e imutáveis ​​depois de criados. Então, o problema de dois clientes tentando usar o mesmo arquivo para conteúdo diferente não aparece.

A outra parte do database de objects é mais complicada – os refs são armazenados em arquivos sob o diretório “refs” (ou em “refs-compactados”) e estes mudam: embora os arquivos refs/* sejam pequenos e sempre reescritos em vez de sendo editado. Nesse caso, o Git grava o novo ref em um arquivo “.lock” temporário e renomeia-o sobre o arquivo de destino. Se o sistema de arquivos respeita a semântica O_EXCL , isso é seguro. Mesmo que não, o pior que poderia acontecer seria uma corrida sobrescrevendo um arquivo de ref. Embora isso seja irritante de se encontrar, não deve causar corrupção como tal: pode ser o caso de você empurrar para o repository compartilhado, e esse push parece ter sido bem-sucedido, enquanto na verdade o de outra pessoa o fez. Mas isso poderia ser resolvido simplesmente puxando (juntando os commits do outro cara) e empurrando novamente.

Em resumo, eu não acho que a corrupção do repository é um problema muito grande aqui – é verdade que as coisas podem dar errado, devido a problemas de bloqueio, mas o design do repository do Git minimizará os danos.

(Aviso: tudo isso soa bem na teoria, mas eu não fiz nenhum marcanvasmento simultâneo de um repository para testá-lo, e apenas compartilhá-los no NFS e não no CIFS)

Porque se importar? O Git é projetado para ser distribuído. Basta ter um repository em cada máquina e usar o mecanismo de publicação e extração para propagar suas alterações entre eles.

Para fins de backup, execute uma tarefa noturna para copiar seu repository para o compartilhamento.

Ou, crie um repository cada no compartilhamento e faça seu trabalho com eles, mas use-os como repositorys distribuídos dos quais você pode extrair conjuntos de alterações uns dos outros. Se você usar esse método, o desempenho de construções e assim por diante será reduzido, pois você estará constantemente acessando pela rede.

Ou, distribuí repositorys em seus próprios computadores e execute uma tarefa periódica para enviar seus commits para os repositorys no compartilhamento.

Aparentemente, o uso de um repository git central é suportado. A maioria dos usos prescritos indica access ssh ou http, nenhum dos quais evita o access simultâneo ao repo. Mesmo se você estiver fazendo uso completamente distribuído, essa questão surge se mais de dois colaboradores enviarem o mesmo repo para qualquer lugar. Até agora, nenhuma resposta respondeu à pergunta. O design do git permite manipular N impulsos simultâneos para uma ramificação?

Soa como se você preferisse usar um sistema de version control centralizado, então a consulta de backup é satisfeita. Talvez com xxx2git entre você para trabalhar localmente.