Concurrence dans un référentiel GIT sur un dossier partagé en réseau

Question

Je veux avoir un nu-dépôt git stockées sur un (windows) partage réseau. J'utilise linux, et ledit réseau de partage de monté avec CIFS. Mon coleague utilise windows xp, et a l'action du réseau automatiquement (à partir de ActiveDirectory, en quelque sorte) comme un lecteur réseau.

Je me demande si je peux utiliser le repo de deux ordinateurs, sans les problèmes de simultanéité.

J'ai déjà testé, et sur ma fin, je peux cloner ok, mais j'ai peur de ce qui pourrait arriver si nous avons tous deux ont accès à la même repo (push/pull), dans le même temps.

Dans le git FAQ il y a une référence sur l'utilisation des systèmes de fichiers réseau (et quelques problèmes avec SMBFS), mais je ne suis pas sûr si il ya quelque verrouillage de fichier par le réseau/serveur/windows/linux - j'en suis sûre, il n'y en a pas.

Donc, quelqu'un a utilisé un repo git sur un partage réseau, sans serveur et sans problèmes?

Merci,
Alex

PS: je tiens à éviter l'utilisation d'un serveur http (ou git-daemon), parce que je n'ai pas accès au serveur avec les actions. Aussi, je sais que nous pouvons juste pousser/tirer de l'un à l'autre, mais nous sont nécessaires pour avoir le code/repo sur la quote-part pour des raisons.

Mise à jour:

Mes soucis ne sont pas sur la possibilité d'une défaillance du réseau. De même, nous avons l'branches localement, et nous allons être en mesure de compiler nos sources.

Mais, nous avons l'habitude de commettre assez souvent, et la nécessité de rebase/fusionner souvent. De mon point de vue, la meilleure option serait d'avoir une centrale repo sur l'action (si les sauvegardes sont assurées), et nous permettrait à la fois de clone de celui-là, et l'utiliser pour rebase.

Mais, en raison du fait que nous le faisons souvent, j'ai peur à propos de fichier/pensions de la corruption, s'il arrive que tous les deux nous pousser/tirer en même temps. Normalement, on pourrait crier les uns sur les autres à chaque fois que nous avons accès à la télécommande repo :), mais il serait mieux de l'avoir garanti par l'ordinateur/réseau.

Et, il est possible que GIT a un mécanisme interne pour ce faire (puisque quelqu'un peut pousser à l'un de vos repos, pendant que vous travaillez sur elle), mais je n'ai rien trouvé de concluant encore.

Mise à jour 2:

Les pensions de titres sur le lecteur partage serait un nu pensions, ne contenant pas d'une copie de travail.

Answer 1

Git nécessite un minimum de verrouillage de fichier, qui, je crois, est la principale cause des problèmes lors de l'utilisation de ce type de ressource partagée sur un réseau de système de fichiers. La raison pour laquelle il peut s'en tirer avec cela est que la plupart des fichiers dans un repo Git--- tous ceux qui forment l'objet de base de données--- sont nommés comme un résumé de leur contenu, et immuable une fois créé. Donc, il y a le problème des deux clients d'essayer d'utiliser le même fichier pour les différents contenus ne sont pas venus.

L'autre partie de l'objet de base de données est plus difficile-- les refs sont stockées dans des fichiers en vertu de la "refs" directory (ou "paniers-refs") et cela ne change: bien que l' refs/* des fichiers sont petits et toujours réécrit plutôt que d'être édité. Dans ce cas, Git écrit le nouveau réf temporaire ".verrouillage de fichier" et renomme ensuite sur le fichier cible. Si le système de fichiers respecte O_EXCL de la sémantique, c'est sûr. Même si pas, le pire qui pourrait arriver serait une course de l'écrasement d'un fichier de référence. Bien que ce serait ennuyeux de rencontre, il ne devrait pas causer de la corruption en tant que telle: ça pourrait être le cas que vous poussez le repo, et qui semble bien que, il a réussi, alors qu'en fait quelqu'un d'autre l'a fait. Mais ce pourrait être résolu simplement en tirant (fusion dans l'autre gars s'engage) et pousser à nouveau.

En résumé, je ne pense pas que les pensions de la corruption est trop un problème ici--- il est vrai que les choses peuvent aller un peu de mal à cause de problèmes de verrouillage, mais la conception de la repo Git permettra de minimiser les dégâts.

(Avertissement: tout cela sonne bien en théorie, mais je n'ai pas fait simultanées du coup de pensions de faire un test, et seulement de les partager sur NFS pas CIFS)

Answer 2

Pourquoi s'embêter? Git est conçu pour être distribué. Juste un référentiel sur chaque machine et de l'utilisation de la publier et de mécanisme d'extraction pour propager vos modifications entre eux.

À des fins de sauvegarde, exécutez chaque soir une tâche de copie de votre référentiel pour l'action.

Ou, créer un référentiel de chacun sur la partager et de faire votre travail, mais de les utiliser comme des référentiels distribués à partir de laquelle vous pouvez tirer les révisions les uns des autres. Si vous utilisez cette méthode, puis performances de faire des builds et ainsi de suite) sera diminué depuis que vous serez constamment accéder sur le réseau.

Ou, ont distribué des dépôts sur votre propre ordinateur et exécuter une tâche périodique de pousser votre s'engage à les dépôts sur le partage.

Answer 3

Cela semble juste comme si vous préfériez utiliser un système de gestion de version centralisé, de sorte que la requête pour la sauvegarde est satisfaite. Peut-être avec xxx2git entre vous pour que vous puissiez travailler localement.