Concurrency в репозитории GIT в общей сетевой папке

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

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

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

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

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

Спасибо,
Alex

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

Обновление:

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

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

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

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

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

Репо на диске общего доступа было бы репозиторией bare, не содержащим рабочей копии.

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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