Concorrenza in un repository GIT su una cartella condivisa di rete

Voglio avere un repository git nudo memorizzato su una condivisione di rete (Windows). Io uso Linux e ho la suddetta condivisione di rete montata con CIFS. Il mio collega usa windows xp e ha la condivisione di rete automounted (da ActiveDirectory, in qualche modo) come unità di rete.

Mi chiedo se posso utilizzare il repository da entrambi i computer, senza problemi di concorrenza.

Ho già provato, e alla fine posso clonare bene, ma ho paura di cosa potrebbe succedere se entrambi accediamo allo stesso repo (push / pull), allo stesso tempo.

Nelle FAQ git c’è un riferimento sull’utilizzo dei file system di rete (e alcuni problemi con SMBFS), ma non sono sicuro che ci sia un blocco di file fatto dalla rete / server / windows / linux – sono abbastanza sicuro che non ci sia ‘t.

Quindi, qualcuno ha mai usato un repository git su una condivisione di rete, senza un server e senza problemi?

Grazie,
alex

PS: Voglio evitare di usare un server http (o il demone git), perché non ho accesso al server con le condivisioni. Inoltre, so che possiamo semplicemente spingere / tirare da uno all’altro, ma ci viene richiesto di avere il codice / repo sulla condivisione per motivi di riserva.

Aggiornare:

Le mie preoccupazioni non riguardano la possibilità di un errore di rete. Anche così, avremmo i rami necessari a livello locale e saremo in grado di compilare le nostre fonti.

Ma di solito ci impegniamo molto spesso e abbiamo bisogno di rebase / merge spesso. Dal mio punto di vista, l’opzione migliore sarebbe avere un repository centrale sulla condivisione (quindi i backup sono assicurati) e dovremmo clonarli entrambi e usarli per rebase.

Ma, a causa del fatto che lo stiamo facendo spesso, temo la corruzione di file / repo , se accade che entrambi spingiamo / tiriamo allo stesso tempo. Normalmente, potremmo urlarci l’un l’altro ogni volta che accediamo al repository remoto :), ma sarebbe meglio tenerlo protetto dai computer / dalla rete.

E, è ansible che GIT abbia un meccanismo interno per farlo (dato che qualcuno può spingere su uno dei tuoi repository, mentre ci lavori), ma non ho ancora trovato nulla di conclusivo.

Aggiornamento 2:

Il repository sul disco condiviso sarebbe un repository nudo , non contenente una copia funzionante.

Git richiede un blocco minimo dei file, che credo sia la causa principale dei problemi nell’utilizzo di questo tipo di risorsa condivisa su un file system di rete. Il motivo per cui può farcela è che la maggior parte dei file in un repository Git – tutti quelli che formano il database degli oggetti – sono nominati come un riassunto del loro contenuto, e immutabili una volta creati. Quindi, non si presenta il problema di due client che cercano di utilizzare lo stesso file per contenuti diversi.

L’altra parte del database degli oggetti è più complicata – gli arbitri sono memorizzati in file sotto la directory “refs” (o in “packed-refs”) e questi cambiano: sebbene i file refs/* siano piccoli e sempre riscritti anziché in corso di modifica. In questo caso, Git scrive il nuovo riferimento in un file “.lock” temporaneo e quindi lo rinomina sul file di destinazione. Se il filesystem rispetta la semantica O_EXCL , è sicuro. Anche se no, il peggio che potrebbe accadere sarebbe una gara che sovrascrive un file ref. Anche se questo sarebbe fastidioso da incontrare, non dovrebbe causare la corruzione in quanto tale: potrebbe essere il caso che si spinga al repository condiviso, e quella spinta sembra riuscita, mentre in realtà lo ha fatto qualcun altro. Ma questo potrebbe essere risolto semplicemente tirando (unendosi ai commit dell’altro) e spingendo di nuovo.

In sintesi, non penso che la corruzione del repository sia troppo un problema qui — è vero che le cose possono andare un po ‘male a causa dei problemi di blocco, ma il design del repo Git minimizzerà il danno.

(Disclaimer: tutto questo suona bene in teoria, ma non ho fatto nessun martellamento concomitante di un repository per testarlo e condividerli solo su NFS e non su CIFS)

Perché preoccuparsi? Git è progettato per essere distribuito. Basta avere un repository su ogni macchina e utilizzare il meccanismo di pubblicazione e pull per propagare le modifiche tra di loro.

Ai fini del backup, eseguire un’attività notturna per copiare il repository nella condivisione.

Oppure, crea un repository ciascuno sulla condivisione e fai il tuo lavoro da loro ma usali come repository distribuiti dai quali puoi estrarre i changeset gli uni dagli altri. Se si utilizza questo metodo, le prestazioni di build e così via verranno ridotte poiché si accederà costantemente alla rete.

Oppure, hai distribuito repository sui tuoi computer ed esegui un’attività periodica per spingere i tuoi commit ai repository sulla condivisione.

Apparentemente è supportato un repository git centrale. Gli usi più prescritti indicano l’accesso SSH o HTTP, nessuno dei quali evita l’accesso simultaneo al repository. Anche se stai facendo un uso completamente distribuito, questa domanda si pone se più di due collaboratori spingono allo stesso repository ovunque. Finora, nessuna risposta ha risposto alla domanda. Il design di git gli consente di gestire N spinte simultanee a un ramo?

Sembra proprio come se si preferisse usare un sistema di controllo delle versioni centralizzato, quindi la query per il backup è soddisfatta. Forse con xxx2git in mezzo affinchè tu possa lavorare localmente.