Может ли файловый репозиторий SVN поддерживать одновременную многопользовательскую ситуацию? - PullRequest
4 голосов
/ 11 ноября 2011

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

Ответы [ 3 ]

4 голосов
/ 11 ноября 2011

Из книги Subversion:

Доступ к хранилищу Subversion может осуществляться одновременно клиентами, работающими на той же машине, на которой находится хранилище, с использованием URL-адресов, содержащих схему file: //. Но типичная настройка Subversion включает в себя доступ к одному серверу с клиентов на компьютерах по всему офису или, возможно, по всему миру.

Существует несколько проблем со схемой file://:

  • Он должен быть на том же сервере. Есть люди, которые помещают репозиторий в общий ресурс Windows или на диск NFS, а затем заставляют людей монтировать общий ресурс и использовать схему file://. Это не будет работать. Для работы схемы доступа file:// она должна быть на одном компьютере.
  • Это небезопасно. Это самая большая проблема. Все пользователи должны иметь разрешение на чтение / запись для файлов в хранилище, что означает, что кто-то может удалить хранилище или просмотреть файлы за спиной Subversion.
  • Использование svn:// и http:// не так сложно в настройке. Я использую Subversion в качестве своей собственной системы контроля версий и использую схему svn://. Subversion с http:// немного сложнее, но я могу сделать это примерно через час.
2 голосов
/ 11 ноября 2011

Просто чтобы поделиться своим прошлым опытом.

В моей компании был проект, размещенный на SVN.Первоначально команда разработчиков использовала протокол file: // для доступа к хранилищу на общем томе SMB.Честно говоря, кажется, работает нормально.Однако производительность просто ужасна.Когда я говорю ужасно, это все равно что тратить минуты на обновление / фиксацию.Более того, я думаю, что вы можете увидеть подобное утверждение из разных источников или ссылки: file: // протокол, предназначенный только для однопользовательского доступа на локальном компьютере.

Когда я участвую в проекте, я сразу же переключаюсь на использование svnserveдля специальной стратегии многопользовательского доступа (хотя я лично использую http для других управляемых мной хранилищ svn).Мы сразу увидели улучшение производительности на порядок.Дополнительное время для установки составляет всего 2 минуты (так как у нас есть сервер, который я могу просто запустить svnserve в режиме консоли и оставить его включенным).Если вы действительно не можете организовать какую-либо машину для запуска svnserve / apache, я не вижу причин придерживаться протокола file: // для многопользовательского доступа.

2 голосов
/ 11 ноября 2011

Коммиты Subversion разработаны так, чтобы быть атомарными.Поэтому одновременное использование нескольких номеров редакций несколькими пользователями должно быть невозможным.Из книги подрывной деятельности :

Операция фиксации SVN публикует изменения любого количества файлов и каталогов в виде одной атомарной транзакции.В вашей рабочей копии вы можете изменить содержимое файлов;создавать, удалять, переименовывать и копировать файлы и каталоги;и затем зафиксируйте полный набор изменений как атомарную транзакцию.

Под атомарной транзакцией мы подразумеваем просто это: либо все изменения происходят в репозитории, либо ни одно из них не происходит.Subversion пытается сохранить эту атомарность перед лицом сбоев программ, сбоев системы, проблем с сетью и действий других пользователей.

Каждый раз, когда репозиторий принимает коммит, это создает новое состояние дерева файловой системы, которое называетсяпересмотр.Каждой ревизии присваивается уникальный натуральный номер, на один больше номера предыдущей ревизии.Первоначальная версия только что созданного репозитория имеет номер 0 и состоит только из пустого корневого каталога.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...