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

Question

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

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

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

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

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

Спасибо,
Alex

PS: Я хочу, чтобы избежать использования сервера HTTP (или ГИТ-демон), потому что у меня нет доступа к серверу с акциями. Кроме того, я знаю, что мы можем просто нажать/вытащить из одного в другой, но мы должны иметь код/​​репо на акции по резервным причинам.

Обновление:

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

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

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

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

Update 2:

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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