Может ли файловый репозиторий SVN поддерживать одновременную многопользовательскую ситуацию?

Question

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

Answer 1

Коммиты Subversion разработаны так, чтобы быть атомарными. Следовательно, несколько пользователей, совершающих один и тот же номер ревизии в одно и то же время, должны быть невозможны. Из книги подрывной деятельности:

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

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

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

Answer 2

Из книги Subversion:

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

Есть несколько проблем с file:// схема:

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

Answer 3

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

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

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