Параллелизм в репозитории GIT в общей сетевой папке

Question

Я хочу иметь пустой git-репозиторий, хранящийся в сетевой папке (windows). Я использую Linux, и у меня есть указанный сетевой ресурс, смонтированный с CIFS. Моя коллега использует Windows XP и автоматически подключает сетевой ресурс (как-то из ActiveDirectory) в качестве сетевого диска.

Интересно, смогу ли я использовать репо с обоих компьютеров без проблем с параллелизмом?

Я уже тестировал, и со своей стороны могу нормально клонировать, но я боюсь того, что может случиться, если мы оба получим доступ к одному и тому же репо (push / pull) одновременно.

В git FAQ есть ссылка на использование сетевых файловых систем (и некоторые проблемы с SMBFS), но я не уверен, есть ли какая-либо блокировка файлов, выполняемая сетью / сервером / windows / linux - я вполне конечно нет.

Итак, кто-нибудь использовал git-репо на сетевом ресурсе, без сервера и без проблем?

Спасибо,
Alex

PS: я хочу избежать использования http-сервера (или git-daemon), потому что у меня нет доступа к серверу с общими ресурсами. Кроме того, я знаю, что мы можем просто выталкивать / извлекать данные из одного в другое, но мы должны иметь код / ​​репо на общем ресурсе по причинам резервного копирования.

Обновление:

Я беспокоюсь не о возможности сбоя сети. Тем не менее, у нас будут необходимые ветки локально, и мы сможем скомпилировать наши источники.

Но мы обычно совершаем довольно часто, и нам нужно часто делать ребазинг / слияние. С моей точки зрения, лучшим вариантом было бы иметь центральное репо на общем ресурсе (так что резервные копии гарантированы), и мы оба клонировали бы с этого и использовали его для перебазирования.

Но из-за того, что мы делаем это часто, я боюсь о повреждении файла / репо , если случится так, что мы оба пушим / тянем одновременно. Обычно мы можем кричать друг на друга каждый раз, когда мы получаем доступ к удаленному репо :), но было бы лучше обеспечить его защиту компьютерами / сетью.

И, возможно, у GIT есть внутренний механизм для этого (поскольку кто-то может нажать на одно из ваших репозиториев, пока вы над ним работаете), но я пока не нашел ничего убедительного.

Обновление 2:

Репо на общем диске будет представлять собой голое репо, не содержащее рабочую копию.

Answer 1

Git требует минимальной блокировки файлов, что, по моему мнению, является основной причиной проблем при использовании такого общего ресурса через сетевую файловую систему. Причина, по которой это может сойти с рук, заключается в том, что большинство файлов в репозитории Git - все те, которые образуют объектную базу данных - называются дайджестом своего содержимого и неизменными после создания. Таким образом, проблема двух клиентов, пытающихся использовать один и тот же файл для разного контента, не возникает.

Другая часть объектной базы данных более хитрая - ссылки хранятся в файлах в каталоге "refs" (или в "pack-refs"), и они меняются: хотя файлы refs/* маленькие и всегда переписан, а не отредактирован. В этом случае Git записывает новый ref во временный файл «.lock», а затем переименовывает его в целевой файл. Если файловая система соблюдает семантику O_EXCL, это безопасно. Даже если нет, то худшее, что может случиться, это гонка, перезаписывающая файл ссылок. Хотя с этим было бы неприятно сталкиваться, это не должно вызывать коррупцию как таковую: это может быть случай, когда вы продвигаетесь к общему репо, и этот толчок выглядит как успешный, тогда как на самом деле это сделал кто-то другой. Но это можно решить, просто потянув (объединяя коммиты другого парня) и нажав снова.

Таким образом, я не думаю, что повреждение репо здесь является слишком большой проблемой - это правда, что все может пойти не так из-за проблем с блокировкой, но дизайн репозитория Git минимизирует ущерб.

(Отказ от ответственности: теоретически все это звучит хорошо, но я не проводил параллельных операций по репо, чтобы проверить их, а делю их только через NFS, а не CIFS)

Answer 2

Зачем беспокоиться? Git предназначен для распространения. Просто создайте репозиторий на каждой машине и используйте механизм публикации и извлечения для распространения ваших изменений между ними.

В целях резервного копирования запустите ночное задание, чтобы скопировать репозиторий в общий ресурс.

Или создайте по одному репозиторию на общем ресурсе и выполняйте за них свою работу, но используйте их как распределенные репозитории, из которых вы можете извлекать наборы изменений друг из друга. Если вы используете этот метод, производительность выполнения сборок и т. Д. Будет снижена, поскольку вы будете постоянно получать доступ по сети.

Или распределите репозитории на своих компьютерах и выполните периодическое задание, чтобы отправить свои коммиты в репозитории на общем ресурсе.

Answer 3

Видимо использование центрального репозитория git поддерживается. Большинство предписанных применений указывают на доступ по ssh или http, ни один из которых не позволяет избежать одновременного доступа к репо. Даже если вы используете полностью распределенное использование, этот вопрос возникает, если более двух соавторов отправляют в одно и то же репо. До сих пор ни один ответ не ответил на вопрос. Позволяет ли дизайн git обрабатывать N одновременных нажатий на ветку?

Answer 4

Звучит так же, как если бы вы предпочли использовать централизованную систему управления версиями, поэтому запрос на резервное копирование удовлетворен. Возможно, с xxx2git между ними вы сможете работать локально.